Req #74851 [Com]: uniqid performances

From: Date: Wed, 19 Jul 2017 02:42:12 +0000
Subject: Req #74851 [Com]: uniqid performances
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-210124@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74851&edit=1 ID: 74851 Comment by: manu at netbsd dot org Reported by: manu at netbsd dot org Summary: uniqid performances Status: Open Type: Feature/Change Request Package: Performance problem Operating System: NetBSD PHP Version: 7.1.6 Block user comment: N Private report: N New Comment: I uploaded an updated patch against git, using ZEND_TLS. Previous Comments: ------------------------------------------------------------------------ [2017-07-18 21:18:12] nikic@php.net This looks like a good approach. I tested your patch on Linux against a tight uniqid() loop and got an improvement of approximately 1000x. One technical note: As written the code is not thread safe. The prev_tv variable should be declared as a thread-local variable. To avoid messing with TSRM globals, it can be declared as ZEND_TLS. ------------------------------------------------------------------------ [2017-07-08 14:56:52] manu at netbsd dot org I just uploaded a third patch that improves the fix to the problem: - uinqid() semantics is not altered: it still output a 14 digit unique identifier - performance boost is obtained for all supported platforms, no uuidgen() support required. - Cygwin requirement to use more_entropy=true can be removed The idea is to poll time using gettimeofday() until the microsecond changes. On a modern system, that will cause a a few gettimeofday() system calls that last much shorter that usleep(1). I measured a 10000-fold performance improvement on NetBSD, and I expect at least a 10-fold improvement on Linux. ------------------------------------------------------------------------ [2017-07-05 15:51:03] manu at netbsd dot org I updated the patch to just extract the nanosecond timestamp of UUID so that we do not introduce non digits in the output. That might have confused some script that do not expect it. I also avoid goind the UUID way if more_entropy is set. ------------------------------------------------------------------------ [2017-07-05 02:11:18] manu at netbsd dot org Right, we have a double constraint: do not change output format for backward compatibility, but also change it to increase performance and uniqueness. Some proposed to deprecate uniqid(), but this does not address the backward compatibility ptoblem, quite the contrary. What about adding an uniqid.version option to php.ini to govern uniqid() behavior? Default would uniqid.version=0 for backward compatible behavior, and uniqid.version=1 would enable UUID output. ------------------------------------------------------------------------ [2017-07-04 23:25:01] nikic@php.net This has been discussed a couple of times already and the argument is basically always the same: We're don't want to change the uniqid output format for BC reasons. In particular changing the length is problematic, as uniqid output is stored in length-limited database fields (for example). Switching uniqid to use UUIDs would certainly cause breakage. There is an active proposal to expose a UUID interface (without changing the uniqid function): https://wiki.php.net/rfc/uuid I think what we should do here is deprecate uniqid() in favor of bin2hex(random_bytes(16)), or the proposed UUID interface. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74851 -- Edit this bug report at https://bugs.php.net/bug.php?id=74851&edit=1

« previous php.bugs (#210124) next »