3 UDSEntry optimizations

[Mark Gaiser]

On Sun, Jul 19, 2015 at 11:11 PM, Mark Gaiser <markg85 at gmail.com> wrote:

> Hi,
>
> I just pushed 3 UDSEntry changes to gerrit for your reviewing pleasure:
>
>   1: https://gerrit.vesnicky.cesnet.cz/r/#/c/473/
>   2: https://gerrit.vesnicky.cesnet.cz/r/#/c/474/
>   3: https://gerrit.vesnicky.cesnet.cz/r/#/c/475/
>
> The end result is a faster UDSEntry in every way. The benchmark results
> (which are from udsentrybenchmark) can be found here:
> http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=c936cdced4
>
> So.. what did i do this time? Initially i wanted to get rid of the extra
> bookkeeping without loss of speed or increasing memory usage. This was
> basically an experiment to see if i could get that working. I was guessing
> that a linear lookup (using std::find_if) would be equally fast as
> QVector::contains(). That turned out to be that case as you can see in the
> benchmarks.
>
> Next up i wanted to use more advanced C++11 that QVector simply doesn't
> allow: emplace_back:
> http://en.cppreference.com/w/cpp/container/vector/emplace_back My guess
> was that it would allow for quite some speedups in inserting because
> objects would be created in place instead of created and copied (or moved).
> Looks like i was right since the benchmarks for creating entries have been
> improved quite a bit.
>
> While at it, also implemented move semantics :)
>
> In terms of memory consumption these patches don't change much. Browsing a
> massive folder (500.000 files) in dolphin without this patch series took
> ~710MB, with it the figure was about 705MB. A saving, but nothing much
> compared tot the total usage.
>
> I would like to know what you folks think of these improvements.
> I really wonder how much more performance i can squeeze out of UDSEntry.
>
> Regarding gerrit. How can i make patch 2 and 3 dependent on 1?
> And why is gerrit failing?
>
> Best regards,
> Mark
>

New benchmark link, the other one expired..
http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=ae6e9e4851 (expires
in one month)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150723/24965bc4/attachment.htm>