RE: [SMARTY-DEV] Is Smarty using PHP output buffering?

Some thoughts IMHO smarty should default to the most efficient option when many leaving a switch so specific installations can change the setting to the not-so-efficient option if they have a problem (ie: low memory). That's why in my opinion display should use OB by default. Why force developers to use OB to gain performance if Smarty can do it transparently? If display with OB is faster than display without OB display should use OB by default and there should be an option to turn OB off if the devel/sysadmin wants to do it for some reason. I think we should even add a swith to the Smarty class to use gzipped output, applications using Smarty in web servers without mod_gzip may benefit a lot of this switch. Since if mod_gzip or similar is used this is highly redundant I think Smarty should default to OB on without compression. I understand that if gzip is used OB is also redudant but tests show that the performance is almost the same so we can default to OB on without any visible problem. Since fetch is already using OB from a developer point of view fetch and display should work identically being the only difference that display outputs the result while fetch doesn't. Somehow my tests show that echo fetch is even faster than ob_start and then display(), maybe somebody can explain this. Of course I'm not complaining or yelling, I just think we have a good opportunity to improve Smarty performance so why not use it? > -----Original Message----- > From: Tom Anderson [mailto:toma@etree.org] > Sent: Tuesday, May 06, 2003 6:19 PM > To: 'Smarty Dev' > Subject: RE: [SMARTY-DEV] Is Smarty using PHP output buffering? > > > It's fine to use OB, but I still don't think it's up to > Smarty to turn it on for the user. > > There are a lot of ways to speed up pages using output > buffering, but, per the manual: > http://www.php.net/manual/en/function.ob-gzhandler.php > "Also > note that using ini.zlib.output_compression is preferred > over ob_gzhandler()." > > If you feel really strongly about the benefits of Smarty + > OB, then I think a section should be added to the Tips and > Tricks which explains output buffering, why it's good, what > options are ideal, and how to do it. Even put notes in > http://smarty.php.net/manual/en/installing.smarty.basic.php > pointing to the appendix and recommend OB is turned on at the > same time a smarty object is created. > > Tom > > -----Original Message----- > From: luis [mailto:luis@fuegolabs.com] > Sent: Tuesday, May 06, 2003 3:16 PM > To: 'Monte Ohrt' > Cc: 'Tom Anderson'; 'Smarty Dev' > Subject: RE: [SMARTY-DEV] Is Smarty using PHP output buffering? > > > I think it's worth comparing the degradation when using OB in > conjuction with mod_gzip versus the improvement of using it. > If we have App foo without > OB: 3 secs App foo with OB: 2.5 secs App foo with gzip > without OB: 2.25 secs APP foo with gzip with OB 2.30 secs > Then the case for using OB is strong. > > > -----Original Message----- > > From: Monte Ohrt [mailto:monte@ispi.net] > > Sent: Tuesday, May 06, 2003 6:12 PM > > To: luis > > Cc: 'Tom Anderson'; Smarty Dev > > Subject: RE: [SMARTY-DEV] Is Smarty using PHP output buffering? > > > > > > There is a disadvantage, it was just mentioned. Those using > mod_gzip > > on the Apache level see a performance degrade because the > output gets > > buffered twice. In my tests I see a very slight performance degrade > > when using OB in combination with mod_gzip. Is suppose a property > > could be added $use_output_buffering that forced OB on a display() > > call, but the same can be accomplished with echo fetch(), > or turn on > > OB in php.ini to get the benefits across the board. > > > > Monte > > > > On Tue, 2003-05-06 at 16:05, luis wrote: > > > I can't understand how OB falls outside te scope of Smarty > > "except of > > > fetch". If fetch uses OB and is faster than display and > there're no > > > bad side-effects then display should use OB too. If we > discover some > > > disadvantages in using OB I'll > > inmediately retreat > > > the proposal just don't say "it's outside the scope of > > smarty" improving > > > is never outside the scope of Smarty. > > > > > > > -----Original Message----- > > > > From: Tom Anderson [mailto:toma@etree.org] > > > > Sent: Tuesday, May 06, 2003 5:47 PM > > > > To: smarty-dev@lists.php.net > > > > Subject: RE: [SMARTY-DEV] Is Smarty using PHP output buffering? > > > > > > > > > > > > I really think global output buffering for smarty is a bad idea. > > > > For instance, it would slow down a server which has mod_gzip > > > > installed. Doing buffering in php and in apache, as mod_gzip > > > > would, is just using more memory than needed. > > > > > > > > I don't think turning on/off output buffering through a smarty > > > > function is right either. Except in the case of > fetch(), output > > > > buffering falls outside the scope of Smarty. > > > > > > > > Tom > > > > > > > > -----Original Message----- > > > > From: luis [mailto:luis@fuegolabs.com] > > > > Sent: Tuesday, May 06, 2003 2:38 PM > > > > To: 'Thomas Schulz'; smarty-dev@lists.php.net > > > > Subject: RE: [SMARTY-DEV] Is Smarty using PHP output buffering? > > > > > > > > > > > > I disagree. If OB is faster then Smarty should use OB > > > > transparently to the user/developer. It's not fair to ask a > > > > developer to fetch when there's a display method based on > > > > performance issues. The two methods should do the same > internally, > > > > the semantic difference is whether the method outputs > the content > > > > or not. > > > > > > > > --- > > > > Luis Argerich ( ) ASCII Ribbon Campaign > > > > http://tikiwiki.sourceforge.net X against > > > > HTML on email > > > > "There's no spoon" / \ and Usenet posts > > > > > > > > > > > > > -----Original Message----- > > > > > From: Thomas Schulz [mailto:ths@4bconsult.de] > > > > > Sent: Tuesday, May 06, 2003 5:23 PM > > > > > To: smarty-dev@lists.php.net > > > > > Subject: RE: [SMARTY-DEV] Is Smarty using PHP output > buffering? > > > > > > > > > > > > > > > Monte Ohrt schrieb in php.smarty.dev: > > > > > > > > > > > I just ran a test on our CMS front page, gzip enabled, no > > > > > > caching. > > > > > > > > > > > > display() --> 1.724 secs/page > > > > > > echo fetch() --> 1.751 secs/page > > > > > > > > > > Hi, > > > > > > > > > > I think gzip does some output buffering... > > > > > > > > > > When I render the main template of my application, that > > > > includes some > > > > > other templates and plugins (which fetch other > templates) I get > > > > > these results: > > > > > > > > > > display() --> 0.65 secs/page > > > > > echo fetch() --> 0.38 secs/page > > > > > > > > > > But I think there is nothing to change in Smarty. If a > > > > programmer want > > > > > to have full control over output-buffering, he can use > > fetch()... > > > > > > > > > > Thomas. > > > > > > > > > > -- > > > > > http://4bconsult.de > > > > > > > > > > -- > > > > > Smarty Development Mailing List (http://smarty.php.net/) To > > > > > unsubscribe, visit: > > > > > http://www.php.net/unsub.php > > > > > > > > > > > > > > > > > -- > > > > Smarty Development Mailing List (http://smarty.php.net/) To > > > > unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > -- > > > > Smarty Development Mailing List (http://smarty.php.net/) To > > > > unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > > Monte Ohrt <monte@ispi.net> > > > > > > -- > > Smarty Development Mailing List (http://smarty.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > Smarty Development Mailing List (http://smarty.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >