Joshua Sierles wrote:
I must agree that the #1 perceived performance problem with Rails (and
lots of other web development kits) is directly related to the lack of
flushed output. While is essentially an illusion and probably not an
issue for a lot of ‘applications’, many ‘public-facing’ sites rely on
this sort of responsiveness, especially when a page is lamentably full
of advertising and other ignorable elements. However, this is a hard
problem to solve when you want to perform after filters, etc.
Advertising is mostly implemented by embedding images in html, usually
retrieved from completely different servers. I can’t see how flushing
your output buffer prematurely would help there.
Having said that, it would be interesting to see a way to flush output
for ‘optimized’ pages, even if some Rails functionality is limited.
Would this technically be possible without radically modifying the way
the framework works?
It would be necessary to make major changes to request processing, with
questionable value. One major drawback which immediately springs to mind
is that you would need to send out the request headers before knowing
whether the request can be fullfilled at all. This doesn’t sound very
attractive to me.
I’m not convinced it’s worth the implementation effort and there are a
number of other areas which I’d try to improve before diving into output
flushing, but I’ll keep the suggestion in the back of my head.