On Wed, Oct 09, 2002 at 05:43:28PM -0700, Titus Brown wrote:
> -> On Wed, Oct 02, 2002 at 10:01:24AM +0100, Mikhail Sobolev wrote:
> -> > It looks like the publishers of static files use the same constructs:
> -> >
> -> >     f = open (filename)
> -> >     return f.read ()
> -> >
> -> > I wonder how memory effective this is.  And if these are not memory
> -> > effective what would be the best approach for serving big static files?
> -> > (Maybe it would even require some sort of rewriting of HTTPResponse
> -> > code?)
>
> AOLserver and Apache both allow memory-mapping of files -- an OS-level
> service, wherein a file is (you got it!) mapped into memory.  I'm
> not sure what sort of performance gain it gives you for infrequently
> served files, but presumably *some*...
>
> See http://httpd.apache.org/docs/mod/mod_mmap_static.html for more
> info on what Apache does.
Thanks. However your answer makes me think that I did put my question
properly.

> If you're *really* interested in performance, I'd suggest just letting
> the Web server handle requests for files...
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'

That means that this string is to be prepared (somehow) and then it's
returned to quixote.  Quixote stores the value in appropriate variable,
and it uses it for both, for calculating the lenght to put in the
appropriate header, and to return the result itself.  That means that
if, for example, I have some large stuff to serve, I have to load it
into memory, while it may be not necessary (in case, it's an existing
file on the disk, or, if the contents can be generated on fly).

Maybe it were possible (and useful) to return not a string, but some
object with the pre-defined methods, like:

    len -- returns the length of the contents, None if unknown, which
           should be perfectly fine
    read -- as in file objects.

Hope this clarifies a bit what I ask about.

--
Misha