On 10 October 2002, Mikhail Sobolev said:
> Thanks. However your answer makes me think that I did put my question
> properly.

Static files are one thing; if you really don't want Quixote to suck up
memory with file.read(), then don't use a static-files-via-Quixote hack
-- let your web server handle the request directly.

> I am interested not in performance, but in memory effectiveness.
>
> In our case -- we do use quixote, do we not? -- all the output is served
> like I showed:
>
>     return 'output string'

Dynamic pages are something else entirely.  There are a number of
reasons why Quixote works the way it does, ie. build up the entire
response and send it in one go:

  * ease of implementation (the biggest reason)

  * exception handling: if any Python exception can happen at any time
    while generating the response, you really shouldn't start sending
    the response until you're done generating it.  Otherwise, all
    responses will be "200 OK", and pages with errors will be nastily
    truncated.

(At first I thought having a transactional DB in the backend also
affected this, but on reflection I'm not so sure.  Hmmm...)

I occasionally speculate about possible changes to Quixote that would
make it possible to return a response a bit at a time.  This would be
especially nice when the back-end computation takes some time, and
yields incremental results.  It would have to be optional, because it
would screw up Quixote's nice exception handling.  Neil usually tells me
to stop worrying, hardware is getting faster and cheaper all the time,
etc.

Bottom line: if your Quixote application is generating and returning web
pages that are too big to fit into memory, then they're too big to send
out over the network.  Send smaller pages!

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org