From kfm-devel  Sat Sep 21 09:16:27 2013
From: David Faure <faure () kde ! org>
Date: Sat, 21 Sep 2013 09:16:27 +0000
To: kfm-devel
Subject: Re: UDSEntry compression ideas
Message-Id: <2007794.xAKHubejfH () asterix>
X-MARC-Message: https://marc.info/?l=kfm-devel&m=137975464108011

On Friday 20 September 2013 21:31:03 Mark wrote:
> 1. Instead of storing the string as QString, you can also store it as a
> QByteArray and call squeeze after setting string. The places that returns a
> QString simply constructs it QString(...)

That's slower (UTF8 conversion).

> 2. Use the google "sparse_hash_map", It's extremely memory efficient!
> https://code.google.com/p/sparsehash/ reading how it is implemented id also
> very interesting:
> https://sparsehash.googlecode.com/svn/trunk/doc/implementation.html that
> was another "WOW!" moment for me when reading that. The downside, it's
> slower.

I'm not sure how this is applicable to UDSEntry, especially after Frank's 
changes.

> 3. Right now the Field struct stores a QString and a long long. Certainly
> there must be a way to just use one type. I guess QVariant has too much
> overhead to be used, but something like that.

That would be "union" instead of "struct", very simply. I'm not sure why we're 
not using that, actually. You could give it a try (just changing it to union, 
nothing else should be required, since the code already accesses *either* 
m_str or m_long depending on the type. Well, the qdatastream operator probably 
needs to check the type and serialize only one or the other.

> Just my remaining ideas that i can't even implement :) (ok, 1 i can, 2 i
> can likely, but 3.. nope. That requires templating knowledge that i simply
> don't have if possible at all)

Wrong :-)

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5