Re: Re: Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']
| From: | Herbert Groot Jebbink | Date: | Thu, 13 Apr 2023 06:53:06 +0000 |
| Subject: | Re: Re: Possible RFC: $_SERVER['REQUEST_TIME_FLOAT'] | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120014@lists.php.net to get a copy of this message | ||
Op wo 12 apr. 2023 16:04 schreef Rowan Tommins <rowan.collins@gmail.com>:
> On Wed, 12 Apr 2023 at 13:25, Herbert Groot Jebbink <
> herbert@groot.jebbink.nl> wrote:
>
>> fallback for REQUEST_TIME and REQUEST_TIME_FLOAT to hrtime seems not
>> possible, hrtime is not based on the actual time, hrtime can be used to
>> calculate a duration or so, not to retrieve the actual time itself.
>>
>
> Fair enough, but that makes my first question all the more important: are
> there any situations or platforms where generating an hrtime value for
> every request would have a performance penalty?
>
> How does that performance (for everyone) compare with a single call to
> microtime(true) in your application to calculate the duration from
> REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
> using hrtime?
>
ok, valid point, I also found out that setting a REQUEST_TIME_x variable at
that point is too late, the request has been going on for a while, that's
most likely the reason it's coming from the active SAPI and not from the
current time.
Thanks for the feedback, I will not file a RFC