How to handle Out-of-Memory in Konqueror?

[Luciano Montanaro]

On Wednesday 25 February 2004 16:03, Josef Weidendorfer wrote:
> On Wednesday 25 February 2004 15:32, Luciano Montanaro wrote:
> > On Wednesday 25 February 2004 14:30, Josef Weidendorfer wrote:
> > > Yes. But to get summary information, I have to go down recursively to the
> > > deepest level.
> >
> > Sure. But when finished with a "leaf" directory scan, you could sum the
> > statistics and substitute the multiple file nodes with just a "summary"
> > node, thus keeping memory consumption within sane limits.
> 
> Regarding summary info: Shouldn't it be the purpose of fsview to see single 
> large files? It seems better to collaps to "statistic nodes" when it is known 
> that a subdirectory won't be drawn because of it's small size.
> This complicates things, as a window resize will have to rebuild parts of the 
> structure...

You could keep track of, let's say the three largest files, and collaps the rest 
in a "greeked" rectangle, for example. 

If you want to follow the way you are indicating, you could discard data that 
could not be rendered in a large window (let's say, if it could not fit in a 
4000x4000 pixels window, then discard the details.) 

> 
> > > > By the way, 600 bytes per file are a lot. What kind of data are you
> > > > collecting?
> > >
> > > It's simple: fsview uses the TreeMap widget which was not supposed to be
> > > used in this way, but for call hierarchies in KCachegrind. Currently, a
> > > lot of (painting) attributes are stored separately for every rectangle,
> > > which is not needed in the case of fsview, and can be avoided.
> >
> > This may be a useful optimization, but it is not the crucial issue.
> 
> What's the issue? The space complexity linear to the number of files?

The issue is that I think that cutting in half the the per-item 600 bytes,
you can only hope to cut in half the final data-set.
Keeping the tree expansion under control, instead, I expect the memory would not
grow to insane numbers.

> > Well, even if konqueror does not crash, having it thrashing the disk is not
> > good anyway. Fsview is cool, but unless it is made way less memory hungry,
> > it can't really be considered for real use. I really hope that can be fixed
> 
> Disk trashing because of zillions of stats can't be avoided if you look at a 
> top directory. Of course, it is worse if this is complemented by swapping ;-)

Yes, that's what I was referring to.
However, I have seen fsview memory occupation grow to more than 1GB on my 256MB 
machine. It still manage to finish the scan, even if slowly.
But this means that fsview is rarely accessing its own data, anyway.

Ciao,
Luciano