RE: [SMARTY-DEV] Is Smarty using PHP output buffering?
| From: | Monte Ohrt | Date: | Tue, 06 May 2003 21:12:05 +0000 |
| Subject: | RE: [SMARTY-DEV] Is Smarty using PHP output buffering? | ||
| References: | 1 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-1386@lists.php.net to get a copy of this message | ||
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>