Proposal to introduce a KDE::stringCache

[Maksim Orlovich]

On Thu, 26 Feb 2004, Dr. Juergen Pfennig wrote:

> Hello List,
> I am locking for discussion - but I am not (yet) a subscriber of this list. If
> you find that it is architectural stuff I could re-send it to kde-core-devel
>
> ## The story:
>
>   This morning kde-core-devel had some discussion about memory consumption by
> kfm when reading very large folders (there was actually an out-of-memory
> problem). The thread-starter said that each file entry uses 600 bytes.

First of all, it's not really konqueror's normal views that were
discussed, but rather a very fancy graphical view widget. So the
measurements are not relevant for this particular technique

>    How can this be? Answer: an entry uses lots of QStrings and each QString
> has 2 (sometimes 3) blocks of memory allocated. Such strings are: FileName,
> Group, Owner (maybe more). Each of the mentioned strings uses maybe 50 bytes
> x 3 = 150. Here we can help.
>
> ## Similar things:
>
>   When a KDE app starts it is likely that a kdDebug or kdWarning causes the
> kdebugrc file to be loaded. That file often contains tens of entries like:

Not in a release build, no?


> ## Proposal:
>
> In the above examples each QString was created separately - in other words
> even if they contain the same data like "root" or "InfoOutput" this data is
> not shared. Each QString has it's own copy. The information is redundant, we
> increased the entropy without need.

<snip>
Please see KGlobal::staticQString() in kdelibs; or what matches
your design much closer, StringShare in JuK  (GPLd, though, since I stole
the hash from Qt). It should be easy enough  to share the user + group
strings like that. What's a bit trickier is that  the path name is hidden
inside the URL, and it is the bit that is the most  likely to be shared
between instances. Of course, file names should not go
through such a cache, since they're likely to be unique. And, of course,
measuring stuff is also important...