3 UDSEntry optimizations

[Mark Gaiser]

On Fri, Jul 24, 2015 at 10:23 AM, Milian Wolff <mail at milianw.de> wrote:

> On Thursday, July 23, 2015 10:15:20 PM Mark Gaiser wrote:
> > 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)
>
> What unit are these numbers in? How did you obtain them? You should make
> this
> as reproducible as possible, _and_ put this information /and/ the results
> into
> the individual commit messages. If someone will review the change in a few
> years down the road and cannot find this website, how should he figure out
> whether this is still applicable? Or if one wants to come up with some
> improvements, one needs documentation on how to do that. Mixing email, blog
> and commit messages is not a good idea. The commit message should be self
> consistent.
>
> I did say that in this thread. Actually in one of the first lines of this
thread:

quote:
-- 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

Note the part:
"The benchmark results (which are from udsentrybenchmark)"

That line tells it all. It tells the benchmark (which is in kio.git/tests)
i used and the results of that are in the graph. The results are obviously
in "ms" since the benchmark is also in ms. If i change timings to a
different unit i will obviously tell. Making the raw numbers available
seems pointless since that's what the graph represents anyway.

But you're right. I could have been a bit more verbose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150724/f100de03/attachment.htm>