Newcomer, PHP pre-processing, Magic Constants __FILE__ and __LINE__ override with #line like in C

> 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 >

> 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.