Req #74851 [Com]: uniqid performances

From: Date: Sat, 08 Jul 2017 14:57:01 +0000
Subject: Req #74851 [Com]: uniqid performances
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-209920@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 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2017-07-04 23:01:13] manu at netbsd dot org The internals discussion ends with the idea of returning an UUID, which is exactly what the provided patch in this bug report does. ------------------------------------------------------------------------ [2017-07-04 21:38:13] cmb@php.net Note, that there is already a related RFC[1] including a discussion on internals[2]. [1] <https://wiki.php.net/rfc/uniqid> [2] <http://marc.info/?t=147339817200002&r=1&w=2> ------------------------------------------------------------------------ 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 (#209920) next »