Hi,

> -----Original Message-----
> From: Peter Cowburn [mailto:petercowb...@gmail.com]
> Sent: Tuesday, January 2, 2018 2:56 PM
> To: Anatol Belski <a...@php.net>
> Cc: internals@lists.php.net; Niklas Keller <m...@kelunik.com>
> Subject: Re: [PHP-DEV] RE: High resolution timer function
> 
> 
> 
> On 2 January 2018 at 10:43, Anatol Belski <a...@php.net <mailto:a...@php.net> 
> >
> wrote:
> 
> 
>       Hi,
> 
>       > -----Original Message-----
>       > From: Anatol Belski [mailto:weltl...@outlook.de
> <mailto:weltl...@outlook.de> ] On Behalf Of Anatol Belski
>       > Sent: Saturday, December 16, 2017 3:03 PM
>       > To: internals@lists.php.net <mailto:internals@lists.php.net>
>       > Cc: Niklas Keller <m...@kelunik.com <mailto:m...@kelunik.com> >
>       > Subject: [PHP-DEV] High resolution timer function
>       >
>       > Hi,
>       >
>       > I would like to propose a function for high resolution monotonic
> timing. There
>       > was discussions about this before and a PR
> https://github.com/php/php-
>       > src/pull/2368 which has issues and was abandoned. I've filed
>       > https://github.com/php/php-src/pull/2976
> <https://github.com/php/php-src/pull/2976>  with some reworked
>       > implementation.
>       >
>       > A monotonic timer can be usable in several situations besides
> benchmarking.
>       > Having a simple functionality like this in the core should be a useful
> addition. The
>       > current approach is a function returning array of [seconds,
> nanoseconds] and
>       > optionally returning full nanosecond number as int on 64-bit or float
> on 32-bit.
>       > The first way is the most portable. Quite a few platforms are already
> supported
>       > by the current implementation.
>       >
>       > IMHO it should be fine to have a function like this in the core, 
> perhaps
> also a few
>       > helper functions could be useful, too. I would like to pursue 7.3 with
> this. Please
>       > lets check for any concerns in general or with implementation,
> naming, etc.
>       >
>       If there are no further comments or objection, I would like to merge 
> this
> patch anytime soon and see to add a couple of helper functions for
> diff/compare.
> 
> 
> 
> 
> Why is this bypassing the RFC process?
> 
The functionality is obvious and won't cause any BC issues. It was requested 
several times in the past, the patch was around for quite some time in several 
versions. Smaller pieces don't always require RFC. If there's no consent on ML, 
the RFC is required. That's where I stood, at least. The spared effort can be 
invested in some other areas. Is there some concrete concern on your side, 
about the implementation, etc.? I'd be glad to hear any feedback, can go for 
RFC, too.

Regards

Anatol

Reply via email to