Hmm, then it could be fixed, but we shouldn't introduce a new implementation.
Assuming you refer to the large number of output calls, they can be saved
using output buffering - implementing localized buffering in every place is
not a good way to go by. I'm not sure output buffering was already
On Sun, 12 May 2002, Zeev Suraski wrote:
Hmm, then it could be fixed, but we shouldn't introduce a new implementation.
Assuming you refer to the large number of output calls, they can be saved
using output buffering - implementing localized buffering in every place is
I've just noticed
At 17:43 12/05/2002, Sascha Schumann wrote:
I've just noticed that you have kicked out the premier
implementation of the same functionality in favor of the dog
slow old one.
I almost missed those idyllic descriptions :)
Note that relying on output buffering alone is
What inherent flaws? So far, the only difference between them that I could
spot was that php_html_puts() was buggy, and did not convert series of
spaces into nbsp;'s. Otherwise, the only difference was the use of
buffering. I may have missed something, though.
That is not buggy,
At 17:58 12/05/2002, Sascha Schumann wrote:
What inherent flaws? So far, the only difference between them that I could
spot was that php_html_puts() was buggy, and did not convert series of
spaces into nbsp;'s. Otherwise, the only difference was the use of
buffering. I may have missed
What I'm pointing out is that there are no 'inherent flaws' in the 'dog
slow' implementation that we already had for a couple of years. If you
want to add buffering, we can add buffering. There's no point in adding a
specialized buffered implementation.
Well, php_html_puts has several
At 18:24 12/05/2002, Sascha Schumann wrote:
- it is buffering as you already noted without having to rely
on the huge output-buffering infrastructure. I have not
benchmarked it, but I do assume that it is noticably slower
than php_html_puts.
- it is faster due to
I'd *really* like to avoid having two copies of the same code,
though. Please remove the duplicated implementation...
Zeev
At 18:24 12/05/2002, Sascha Schumann wrote:
What I'm pointing out is that there are no 'inherent flaws' in the 'dog
slow' implementation that we already had for a
I favor php_html_puts also due to maintability reasons.
Please consider this part of code from zend_html_puts:
!(((ptr+1)=end) || (*(ptr+1)==' ')) /* next is not a space */
!((ptr==s) || (*(ptr-1)==' '))) /* last is not a space */ {
And contrast it with the
At 18:34 12/05/2002, Sascha Schumann wrote:
I favor php_html_puts also due to maintability reasons.
Please consider this part of code from zend_html_puts:
!(((ptr+1)=end) || (*(ptr+1)==' ')) /* next is not a space */
!((ptr==s) || (*(ptr-1)==' '))) /* last
Ok, so I'll use your method. By the way, there was nothing inherent in the
two places you used 'inherent', on this topic :)
php_html_puts is simple, consistent and easy to follow.
These are its essential characteristics, and thus they are
inherent. But I digress.
Again, I fail
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
I messed up on the test, I left output buffering enabled for tests 2 and
3. So you can see that using output buffering on top of the global output
buffering (whether specialized or not) slows you down by about 30%.
However, to be fair, the numbers w/o global output buffering enabled:
13 matches
Mail list logo
