Re: Re: Any idea why we have two html_puts()'s?

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