Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118875
Message-ID: <623919d8-4618-b976-1282-bbb6c080588a@pouzenc.fr>
Date: Mon, 24 Oct 2022 10:25:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <50321070-3682-c238-d8b4-3d0f6832c4bc@pouzenc.fr>
 <ed836311-ba9c-46e4-844c-0a93d0aa6459@app.fastmail.com>
Content-Language: fr
In-Reply-To: <ed836311-ba9c-46e4-844c-0a93d0aa6459@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Newcomer, PHP pre-processing, Magic Constants __FILE__
 and __LINE__ override with #line like in C
From: ludovic@pouzenc.fr (Ludovic Pouzenc)

Le 23/10/2022 à 18:02, Larry Garfield a écrit :
> On Sun, Oct 23, 2022, at 8:43 AM, Ludovic Pouzenc wrote:
>> Hi,
>>
>> I'm a newcomer here. I came from https://wiki.php.net/rfc/howto.
>>
>> *TL;DR:* I want to know if a proposal of a #line parsing to alter
>> __FILE__ and __LINE__ in PHP like it exists in C could be a good idea.
>>
>> I've searched about __LINE__ and __FILE__ in mailing archives and wiki,
>> I don't really find things matching. I hope it's not because "__" are
>> stripped before search. "Magic constants" didn't help neither. Let me
>> know if I am rethinking and old thing already imagined here in the past.
>>
>> *Background / use case:* I think at first about webservices, maybe the
>> useful also with browser/human-facing use cases.
>>
>> With PHP, it's hard to get high responsiveness under load if user code
>> start by loading a composer's autoload.php, then (lazy) loads a whole
>> framework with 10+ dependencies, then execute 1 SQL request, 1
>> json_encode() then output and exit. Even with "Slim" framework that
>> should be minimal, using only the route feature, I see "strace" counting
>> 200+ file-related syscalls per request with recent
>> linux/debian/apache/php-fpm.
>>
>> It's not so hard to get it better with other langages : when they are
>> compiled, or when framework loading happens at server start and to at
>> each request.
>>
>> Web projects have more and more a "compilation" phase for minimising JS,
>> for proprocessing scss to css, it is possible to hook it some PHP
>> processing too.
>>
>> In my university, I started using a purpose-written PHP Preprocessor to
>> minimize runtime dependency loading. It only understands #include like
>> in C. From a src/mywebservice/v1/some-endpoint.php it will generate and
>> build/mywebservice/v1/some-endpoint.php with all #include
>> "some/path/somedep.php" replaced by the file's contents.
>>
>> So the generated some-endpoint.php have no run-time dependency at all:
>> no autoload, no include(), no require(). I think it evens maximize the
>> gains with APC caching.
>>
>> The preprocessor also generate things like #line 2
>> "some/path/somedep.php" where an #include was encountered, then a thing
>> like #line 47 "src/mywebservice/v1/some-endpoint.php" right after the
>> end of the inclusion. In C, a great concrete example of #line importance
>> is working with a flex/bison parser generator.
>>
>> If PHP parser interpret #line as in C, __FILE__ and __LINE__ Magic
>> Constants will be changed to source file and line, instead of generated
>> file and line. It could greatly improve development write-then-rerun
>> cycle. (missing ";" at line NN , other PHP Errors, Exception details/traces)
>>
>> I hope it could unlock many use cases where "big" PHP frameworks get
>> really hard time to try to compete with other languages equivalents.
>>
>> Do you think it's an idea that is suitable to discuss, improve and
>> submit as an RFC ?
>>
>> Regards,
> It sounds like there are numerous existing approaches to address the situation you describe that are already in use and far more effective than making constants stealthily dynamic.
>
> 1. Opcache preloading, introduced in PHP 7.4.
> 2. Disable the stat calls on opcache, so it doesn't even check the disk at all once something is in cache.
> 3. Use a persistent-process tool like React PHP, AmPHP, Revolt, and the like, so it functions more like Node.js instead of using PHP-FPM.
>
> I think you're also greatly over-estimating how large the startup cost is in practice.  It's real, certainly, but unless you have several nested microservices a well-made framework should have a fairly small overhead.
>
> --Larry Garfield
>
Thanks for replies, I will test tools and features mentionned above.

-- 
Ludovic Pouzenc
www.pouzenc.fr