Re: Mason 1.3 autoflush behaviour change

You make a convincing case...I guess this is the way to go. But I'm 
temped to put a warning in the logs if enable_autoflush is left 
unspecified. :)

Jesse wrote:
> 
> 
> On Wed, Oct 13, 2004 at 09:32:30AM -0700, Jonathan Swartz wrote:
> 
>>I suppose we could also change the default to enable_autoflush=>1. I was 
>>just hoping to make the higher performance option the default, but maybe 
>>that's silly. static_source is the biggest win and it isn't (can't be) 
>>the default anyway.
> 
> 
> Keeping the defaults the same as Mason 1.2x means that folks are more
> likely to upgrade to the newer codebase faster and with fewer hassles.
> I'm _thrilled_ that the optimization work has been going on and looking
> forward to eventually being able to make RT take advantage of it.
> 
> 
>>But Jesse, can I ask how you're using autoflush and why several 
>>well-placed manual $m->flush_buffer calls wouldn't work as well?
> 
> 
> Because RT is a database-driven application with a fairly large amount
> of data behind it, individual page views can sometimes take a fair bit
> of time. Turning on autoflush (and turning it off in a few important
> places was a really quick way to greatly improve RT's _percieved_
> performance. ;) Having to dig through 500+ mason components inserting manual
> flushing is really a really unappealing prospect.   Long-term, it may be
> a better solution than autoflush, but being forced into it by a newer
> Mason appearing on CPAN would be unfortunate.
> 
> 
> Jesse
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl