Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120014 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55035 invoked from network); 13 Apr 2023 06:53:21 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Apr 2023 06:53:21 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 42D4318054F for ; Wed, 12 Apr 2023 23:53:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 12 Apr 2023 23:53:19 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id sg7so46245306ejc.9 for ; Wed, 12 Apr 2023 23:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=groot-jebbink-nl.20221208.gappssmtp.com; s=20221208; t=1681368798; x=1683960798; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=55oE8XiGegtBRLgW2XPoqHHESSIUIM9b0GMsE9HnUv8=; b=Oi8dpHsCSJXg4BHSlu9cb6OPBcZUG1a0KSESUPuothu1y6M1cNnNhgup9K0JIQKJsR go6xzMwf3SSRoIcFJbEbbg7mlvT8IOwCrwqZ3UICRrR6F1GFtT3V0C4cRvoTkeH53/dT qnK3RVYSioYlt3TvpeaYSoGBUUjTwZfF9U/jznL1QvIFPui5xDA+7lI0XXLucYSSoZ7t Eu98FYJSXkeTLOgtrbDclv6BfSrZcjLBZIREP8GwKeWrrqowngvdmF3VUyeoGVigbbsM 8k7dtH2fEEPL9gJgvqjpWfCiuo1nXlXLOdSGjnX7uYYYxL+0EQ9pSZLXkL45PuXsd4KX IueA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681368798; x=1683960798; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=55oE8XiGegtBRLgW2XPoqHHESSIUIM9b0GMsE9HnUv8=; b=anL6MTB/dgj4eVowaMJqjaJy7M2BhekfJjbXr7bVKHlSON5RDEjRzAOfpIONSreKdD Xus0Ynv3EjJYEyCpkSuMM++iLhQzABY2Iv+yKga0TkVfYqw7SXSFn8VEb79znCjpsj9x WoxEnkz05ok+ZY90Iz3cNULwxz2kCg+OmQ28mJs4fcFeO7Pi5mfjWJb8jexXzBp5avsl qi1g5C7cK3qt3rhFigUnxCJQgH8SM2LaNlqelk/0vevDLladmfaz0+QxanlNxGVdFMYy T/XFRWv9cAacS4bq2AVTVY2nMsa2CocITMFJ7dhnND2MAjH4ydWHAQOeUnG5lLeOQnIf fRRQ== X-Gm-Message-State: AAQBX9fEqTV92fTgKAlEg6ocVp/IXT5TmFoyaxNzAXtLwabTCh1Nh8gW jW527IFP6QcxOKD+qO74wp8jT6FnsIWpef1HNEt/m8q3C0czY/7Heds= X-Google-Smtp-Source: AKy350atYq5sDb0ZBSh6ns9jQTnkrj8K/G1RBEpA/uUic9xqZJgx3hDCChNAIl+8Y4COM7BnJZ1NBus4Gihj8sLBEGQ= X-Received: by 2002:a17:906:a08b:b0:930:310:abc9 with SMTP id q11-20020a170906a08b00b009300310abc9mr773085ejy.9.1681368798128; Wed, 12 Apr 2023 23:53:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 13 Apr 2023 08:53:06 +0200 Message-ID: To: Rowan Tommins Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000f3143f05f9322d9a" Subject: Re: [PHP-DEV] Re: Possible RFC: $_SERVER['REQUEST_TIME_FLOAT'] From: herbert@groot.jebbink.nl (Herbert Groot Jebbink) --000000000000f3143f05f9322d9a Content-Type: text/plain; charset="UTF-8" Op wo 12 apr. 2023 16:04 schreef Rowan Tommins : > 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 --000000000000f3143f05f9322d9a--