At 19:00 12/05/2002, Sascha Schumann wrote: > > Again, I fail to understand the logic behind it. I'll change the space > > handling code to your method (which is indeed nicer); Why on earth would > > we need to have a stupid HTML printout function as a function pointer? > > If you would also address the two performance aspects I > mentioned earlier, I would divert from my current stance that > php_html_puts should be used further.
No, I believe that if we decide that performance is important enough, we make php_html_puts() be a wrapper around zend_html_puts() that uses output buffering. The performance difference between an output buffering implementation and a specialized buffered implementation will most probably be negligible. You still haven't said why we should even strive to make html_puts() as efficient as possible. Again, the only place it's being used today is phpinfo(), and in all these years, I've yet to hear about a single person that complained about its performance :) > Oh, wait and there is a third issue I did not think of > earlier. You could find a zillion such places, and it doesn't mean anything. We have an infrastructure for a reason, and it makes sense to work around it only when you have an performance sensitive function, which html_puts() clearly is not. The function pointer dereferences, as well as TSRM fetches, are completely negligible in comparison to the IO performance. A small test I conducted, calling phpinfo(): No buffering: 12 req/s Specialized OB: 36.3 req/s PHP OB (C level, for each separate string): 35.9 req/s PHP OB (userland, for the entire phpinfo()): 50 req/s I still don't think that we should care too much about the performance of this function, but if decide that we do, then turning it into a function pointer is not exactly the right thing to do :) Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
