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

List:       kfm-devel
Subject:    Re: UDSEntry compression ideas
From:       David Faure <faure () kde ! org>
Date:       2013-09-21 9:16:27
Message-ID: 2007794.xAKHubejfH () asterix
[Download RAW message or body]

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

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