3 UDSEntry optimizations

[Milian Wolff]

On Friday, July 24, 2015 06:55:01 PM Mark Gaiser wrote:
> 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.

Yes, as you see I cannot follow you. And again, future people should be able 
to follow as well, thus put information into commit messages and you cannot 
put graphs there.

Also, please use -perf instead, preferably with -perf instr:k and/or cycles:k.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150724/759eee7e/attachment.sig>