# Standard constants as part of the lexer - Thread: https://externals.io/message/53375 - Original archive: https://news-web.php.net/php.internals/53375 - Started by Robert Eisele on 2011-06-20T10:48:51+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53375 — Robert Eisele — 2011-06-20T10:48:51+00:00 URL: https://externals.io/message/53375#53375 The constants true, false and null are used very often. Unfortunately, every usage of either of these constants invokes a constant lookup. There is no problem with this, constant lookups are fast, but I nevertheless implemented these constants directly in the lexer to avoid these lookups. I'd be glad to see this change in 5.4 as the performance enhancement would be a steal. I've also added a new OP code to hard-code `count()` and `strlen()` which improves the performance by ~800%. This is nice, but limits the usage of `count()` and `strlen()` as method name - if no further changes will be made at the parser. I would rather see a optimization for every function call in 5.4.x. I'll take a look at this soon, maybe I can provide a patch for this, too. What do you think about the constants optimization? Unfortunateley, I've broken the power cable of my macbook and have to wait for a new one. I'll deliver in addition the patch if you like the idea. Robert --- ## #53377 — Derick Rethans — 2011-06-20T11:00:16+00:00 URL: https://externals.io/message/53375#53377 · In reply to: #53375 > The constants true, false and null are used very often. Unfortunately, > every usage of either of these constants invokes a constant lookup. > There is no problem with this, constant lookups are fast, but I > nevertheless implemented these constants directly in the lexer to > avoid these lookups. I'd be glad to see this change in 5.4 as the > performance enhancement would be a steal. Would that not break the following code?: true(); ?> > I've also added a new OP code to hard-code `count()` and `strlen()` which > improves the performance by ~800%. This is nice, but limits the usage > of `count()` and `strlen()` as method name - if no further changes will be > made at the parser. I would rather see a optimization for every > function call in 5.4.x. I'll take a look at this soon, maybe I can > provide a patch for this, too. Although it's a nice performance increase, I think that breaking `count()` as a method name is not a good idea, as I would assume it's used a lot. Even though `count()` and `strlen()` can be optimised that much, how much does it buy a fully fledged application? Then there is also the deliberation on whether it's good to go this general direction, because I am sure we can make a case to convert every function into an opcode perhaps. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #53379 — Sebastian Bergmann — 2011-06-20T11:05:43+00:00 URL: https://externals.io/message/53375#53379 · In reply to: #53377 Am 20.06.2011 13:00, schrieb Derick Rethans: > Although it's a nice performance increase, I think that breaking > `count()` as a method name is not a good idea, as I would assume it's > used a lot. Even though `count()` and `strlen()` can be optimised that much, > how much does it buy a fully fledged application? Especially since we have a built-in Countable interface that requires the implementation of a `count()` method. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #53380 — Robert Eisele — 2011-06-20T11:12:58+00:00 URL: https://externals.io/message/53375#53380 · In reply to: #53377 2011/6/20 Derick Rethans > > > > […] > > Would that not break the following code?: > > class bar > { > function true() > { > return true; > } > } > > $A = new bar; > $A->true(); > ?> > Yes, indeed. But as I wrote, we could add T_SIZEOF (symbol for count + strlen) and T_LVAL (used for constants) as exception for method and function names. A more general solution would be better, instead of hacking such things without deep considerations in an official tree. > > > […] > > Although it's a nice performance increase, I think that breaking > `count()` as a method name is not a good idea, as I would assume it's > used a lot. Even though `count()` and `strlen()` can be optimised that much, > how much does it buy a fully fledged application? > I think it depends on the experience of the developers. There are many - halfway ugly - "PHP optimization" tricks on the net. If these are used, the difference wouldn't that much. But constructs like for($i=0; $i > Then there is also the deliberation on whether it's good to go this > general direction, because I am sure we can make a case to convert every > function into an opcode perhaps. > This would make extension development much more complicated. > > cheers, > Derick > > grz Robert > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug --- ## #53406 — Etienne Kneuss — 2011-06-20T14:25:49+00:00 URL: https://externals.io/message/53375#53406 · In reply to: #53380 Hi, > 2011/6/20 Derick Rethans > > > […] > > Yes, indeed. But as I wrote, we could add T_SIZEOF (symbol for count + > strlen) and T_LVAL (used for constants) as exception for method and function > names. A more general solution would be better, instead of hacking such > things without deep considerations in an official tree. Why have them as tokens at all? The optimisation comes from having specific opcodes, not specific tokens. We could keep the current tokens, and thus keeping 100% BC, but check for the content of `T_STRING` tokens at the parsing level, to dispatch to specific OPCodes in such cases. > > > > […] > > I think it depends on the experience of the developers. There are many - > halfway ugly - "PHP optimization" tricks on the net. If these are used, the > difference wouldn't that much. But constructs like for($i=0; $i $i++) could get optimized vigorous. > > > > […] > > This would make extension development much more complicated. > > > > […] > > > > > […] > -- Etienne Kneuss http://www.colder.ch --- ## #53435 — Stas Malyshev — 2011-06-20T17:17:51+00:00 URL: https://externals.io/message/53375#53435 · In reply to: #53380 Hi! > I think it depends on the experience of the developers. There are many - > halfway ugly - "PHP optimization" tricks on the net. If these are used, the > difference wouldn't that much. But constructs like for($i=0; $i $i++) could get optimized vigorous. If you're microoptimizing, you should not do this unless $x is a dynamic string, so I'm not sure messing with strlen is the right way to improve it. Also, I really do not like splitting `strlen()`/count() code into two places. It hurts maintainability and will lead to weird BC problems. I'm not sure if the optimization is worth it, but if it is, it should be done differently, with only one code for any `strlen()`/count() implementation. Also, I don't see why strlen/count should share an opcode if there's absolutely no common implementation code between them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227