Description:
------------
uniqid() uses system microsecond-precise clock to produce an unique identifier. In order to avoid producing the same value, it will always call usleep() to wait for the next microsecond.
The problem here is that usleep() may wait for much longer. According to Opengroup's POSIX, "The suspension time may be longer than requested due to the scheduling of other activity by the system". Indeed tests on NetBSD show that the kernel will schedule another process during the usleep() call, resulting in a typical uniqid() duration around 16 ms, which is around 16000 time slower than intended.
I suggest to address the problem by using uuidgen() system call if available. This system call is not in POSIX standard, but will be available on most modern systems. The call costs around a microsecond, and it produce a much better unique identifier than what uniqid() currently does. Attached is a patch against PHP 7.1.6 that cause PHP's configure script to look up uuidgen(), and that uses it in uniqid() if it is available.
The same problem was reported at lease in bugs #65626, #37106, #37840 and #14248, but with no satisfying fix proposed, in my opinion.
Test script:
---------------
Test to compare uniqid() performance across systems:
time php -r 'for ($i = 0; $i < 1000; $i++) uniqid();'

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-05 02:11 UTC] 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-05 15:51 UTC] 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-08 14:56 UTC] 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.

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.