[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Why is KSpread such a memory hog - analysis
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2004-08-28 15:48:47
Message-ID: 200408281748.48676.nicolasg () snafu ! de
[Download RAW message or body]

From what I see KSpreadCell is the biggest problem, as you store an int, 
adouble, a QString... instead of having something similar to a QVariant. 
(Note: I do not think that using QVariant would be good, as it would not 
solve the problem when/if we would introduce higher mathematical precision 
libraries into KSpread (one day...).)

As for using SAX (QXml) instead of DOM (QDom), well, it is a way but it has 
also drawbacks.

First you have to store the data nevertheless. If you can do it in the final 
classes fine, you have won space (that is what I do in the KWord 1.3 import 
filter). If you need temporary classes, you must be careful that it is less 
complex and uses less memory than QDom or otherwise it is not worth the 
effort.

Also we are an office suite which is supposed to have other objects in 
document. So here too, you must be careful. (For example for KWord 1.3 
format, you can have KFormula data in the KWord document that needs to be 
treated separately. I do not know if KSpread would have a similar problem.)

Have a nice day!

On Saturday 28 August 2004 15:55, Tomas Mecir wrote:
(...)
> There are two classes that should theoretically add up most of this -
> KSpreadCell and KSpreadStyle. There's one instance of KSpreadCell for
> every cell and at most one instance of KSpreadStyle per cell.
> KSpreadCell takes up about 150 bytes, KSpreadStyle about 350 bytes
> (not exact number due to usage of several classes with d-pointers,
> real usage probably lower).
(...)
> Not even a single cell, yet 180 MB RAM usage... There was only one
> possibility - the loader uses all that memory... Loader, that means
> QDom. I realized that I knew nothing about it, so I've digged out some
> description... And there, I found the reason... QDom works by loading
> all the XML file into memory and converting it into hierarchical tree
> of objects... This obviously creates some overhead an'all - overhead
> by a factor of ten or more...
>
> So - what's the moral?
> If we want to reduce memory usage of KSpread, we need to get rid of
> QDom and parse XML with something else that Qt provides... Something
> that reads XML as a stream...
(...)

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]