Re: Opera Memory Fix

Hi,

On 11/16/07, Kevin Kubasik <[email protected]> wrote:
> p.s. Also, our in-memory hashtable of Guid's for the FSQ is immense,
> it would be trivial to change the LuceneNameResolver to use a sqlite
> db to store that data on-disk and out of memory, freeing a few megs. I
> don't know a ton about the FSQ in general, and almost nothing about
> the uid mapping, if this class is super-dynamic then maybe its a bad
> call, but it appears that its a big build at startup, then static.
> Could be a big memory saver.

This is why I keep saying that we need to rewrite the FSQ.

That mapping is how we map the internal GUID URIs to the external,
real but changeable file URIs.  The FSQ essentially creates a parallel
directory tree in memory so that paths and so forth can be quickly
reconstructed.

It might be possible to try to load those on-demand, but I suspect
performance will suffer quite a bit since they would have to be pulled
from the sqlite database.  It might be worth playing around with, but
I think the larger fix is necessary.

Joe