-point number is also slower than formatting an integer.
I have same result; integer version is 0.65 seconds and double version
is 0.82 seconds.
--
Kazuo Oishi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ting result. AFAIK, I didn't get significant difference when I made
>> the patch.
>> What is your system? It seems your PRNG is significantly slow.
Core i7-5600U 2.60GHz
Linux version 4.8.10, gcc version 4.9.3, gentoo
> The performance will be improved by reducing multiple PRNG calls to 1.
> I'll modify patch later, could you test it with your system?
Sure. But as you said, Lauri's version would be optimal.
--
Kazuo Oishi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ster.
No. Lauri's version is better.
Your php_random_bytes_throw() version is significantly slow. Lauri's
version is faster and cleaner.
[original uniqid() using php_combined_lcg]
$ time ./php_uniqid_orig -r 'for($i=0; $i<100;$i++) uniqid("",true);'
real
Obviously, this is not related to your patch. "we must fix due to
proposed PHPMailer bug fix patch" is "FUD". Behavior of uniqid without
$more_entropy=TRUE is not changed.
What's your intention?
BTW, I agree that uniqid() is good enough to use as MIME boundary key, if
colli
ble output).
- Why number of new style entropy ([0-9a-v]+) starts with 13?
(Why not 2 or 11?)
- Why max number of entropy is 255? (32^255 = 1275 bits)
(Ease of implementation?)
And, what will happen when 2-12, greater than 255, or negative
value is specified?
--
Kazuo Oishi
--
PHP Inte
mplementation is good enough for most cases, but it can be better.
I agree this legacy design API works good enough for most cases.
So, I think it should not be changed in BC break way.
--
Kazuo Oishi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
it will be 23 characters.
- if more_entropy is set to TRUE, uniqid() will add additional entropy
(using the combined linear congruential generator) at the end of the
return value
http://php.net/manual/en/function.uniqid.php
So, it is fairly valid to design
- field length limit to 13 chars in va
iously necessary. But this change is not, I think.
> It's much less impact than using mt_rand() all over
> the code. i.e. rand() and mt_rand() is predictable random generator.
Sorry, I cannot understand what you say... (Why mt_rand?)
--
Kazuo Oishi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
described in the RFC. Please read RFC because it's the
> official proposal.
I had read it, of course. But I could not understand why you chose BC
break way.
Now, I understand your intention to change default value of
"more_entropy" despite of BC break. You do want to change the defa
sary BC break. (Why returning string length
is changed?)
If good unique ID generator is needed in core, please create new
function with another name like "unique_id".
--
Kazuo Oishi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
niqid() without more_entropy to
DB, in the search results. Output length change may cause problem in
such case. And you are not supposed to forget that most of php codes
are not open source and not opened to the public.
In addition, you shoud hear "I expect the numbers to grow" a
>> utf8_decode() and utf8_encode() are not needed and causing problems
>> than solving.
>>
>> https://wiki.php.net/rfc/remove_utf_8_decode_encode
...
> I think it would be the best we document deprecation and leave as it is now.
>
> I'll start vote tomorrow. If you have comment, please do so asap.
12 matches
Mail list logo
