How to handle Out-of-Memory in Konqueror?

[Josef Weidendorfer]

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...

> > > 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?

> > > new always returns a valid pointer unless you use nothrow
> > > (e.g. QString pippo = new(nothrow) QString(1000); will return 0 if the
> > > space can't be allocated.)
> >
> > Ah, thanks. I didn't know this. Can this generally be used in KDE code,
> > i.e. are there old compilers we support and which don't allow for this?
>
> It is part of the C++ standard. However, since exceptions are normally
> disabled, you can probably assume the nothrow is implicit.

Obviously for the bug reporters there was an exception raised, so I have to 
include "(nothrow)" to catch both cases (with and without exceptions).

> > Unless you use "ulimit" ;-)
>
> 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 ;-)

Greetings,
Josef

>
> Ciao
> Luciano