[Seaside] memory eating problem

[Avi Bryant]

On Tue, 16 Apr 2002, Kamil Kukura wrote:

> I did little test. First I cleared all templates and sessions:
>
>     IAApplication applications do: [ :app | app reset].

What's #reset?  I assume it's a method you added?

> After this I printed:
>
>     IAVarStack allInstances size 21459

Minesweeper is a particularly nasty example for this, since not only does
it have a lot of links, but each one is in a separate component, which
means that you end up with a few hundred VarStacks for each page view.
So that looks like maybe 100 page views worth.  Now, you probably don't
ever need to actually keep 100 page views of history for a single session.
One way to fix this would be to put each individual game into a separate
transaction (I'm about to commit a change to SSVS that does exactly that).
This should keep memory usage down to reasonable levels.

However, you could easily have even nastier examples, involving thousands
of links on a page.  The VarStack code really needs to be improved for
this case.  Right now, as the class comment attests, it's extremely
inefficient, both in how much storage is allocated in how much of it is
copied.  One way to improve things would be to somehow combine Callbacks
and VarStacks, since there's generally a one-one relationship between
instances of each.  However, I don't think we can easily get away from
storing one object (say, 20 or 30 bytes) for each link or form element on
a cached page view.  This means that caching more than a few million links
concurrently is a problem.  I haven't yet had to worry about that level of
scalability (say you have 10-page transactions, 100 links per page, you
can still have 1000 concurrent sessions).  But if it's a real concern,
we'll do what we can to address it.

Thoughts?

Cheers,
Avi