<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 24, 2015 at 10:23 AM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, July 23, 2015 10:15:20 PM Mark Gaiser wrote:<br>
<span class="">> On Sun, Jul 19, 2015 at 11:11 PM, Mark Gaiser <<a href="mailto:markg85@gmail.com">markg85@gmail.com</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > I just pushed 3 UDSEntry changes to gerrit for your reviewing pleasure:<br>
> >   1: <a href="https://gerrit.vesnicky.cesnet.cz/r/#/c/473/" rel="noreferrer" target="_blank">https://gerrit.vesnicky.cesnet.cz/r/#/c/473/</a><br>
</span>> >   2: <a href="https://gerrit.vesnicky.cesnet.cz/r/#/c/474/" rel="noreferrer" target="_blank">https://gerrit.vesnicky.cesnet.cz/r/#/c/474/</a><br>
> >   3: <a href="https://gerrit.vesnicky.cesnet.cz/r/#/c/475/" rel="noreferrer" target="_blank">https://gerrit.vesnicky.cesnet.cz/r/#/c/475/</a><br>
> ><br>
<span class="">> > The end result is a faster UDSEntry in every way. The benchmark results<br>
> > (which are from udsentrybenchmark) can be found here:<br>
> > <a href="http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=c936cdced4" rel="noreferrer" target="_blank">http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=c936cdced4</a><br>
> ><br>
</span><span class="">> > So.. what did i do this time? Initially i wanted to get rid of the extra<br>
> > bookkeeping without loss of speed or increasing memory usage. This was<br>
> > basically an experiment to see if i could get that working. I was guessing<br>
> > that a linear lookup (using std::find_if) would be equally fast as<br>
> > QVector::contains(). That turned out to be that case as you can see in the<br>
> > benchmarks.<br>
> ><br>
> > Next up i wanted to use more advanced C++11 that QVector simply doesn't<br>
> > allow: emplace_back:<br>
</span><span class="">> > <a href="http://en.cppreference.com/w/cpp/container/vector/emplace_back" rel="noreferrer" target="_blank">http://en.cppreference.com/w/cpp/container/vector/emplace_back</a> My guess<br>
> > was that it would allow for quite some speedups in inserting because<br>
> > objects would be created in place instead of created and copied (or<br>
> > moved).<br>
> > Looks like i was right since the benchmarks for creating entries have been<br>
> > improved quite a bit.<br>
> ><br>
> > While at it, also implemented move semantics :)<br>
> ><br>
> > In terms of memory consumption these patches don't change much. Browsing a<br>
> > massive folder (500.000 files) in dolphin without this patch series took<br>
> > ~710MB, with it the figure was about 705MB. A saving, but nothing much<br>
> > compared tot the total usage.<br>
> ><br>
> > I would like to know what you folks think of these improvements.<br>
> > I really wonder how much more performance i can squeeze out of UDSEntry.<br>
> ><br>
> > Regarding gerrit. How can i make patch 2 and 3 dependent on 1?<br>
> > And why is gerrit failing?<br>
> ><br>
> > Best regards,<br>
> > Mark<br>
><br>
> New benchmark link, the other one expired..<br>
</span>> <a href="http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=ae6e9e4851" rel="noreferrer" target="_blank">http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=ae6e9e4851</a> (expires<br>
> in one month)<br>
<br>
What unit are these numbers in? How did you obtain them? You should make this<br>
as reproducible as possible, _and_ put this information /and/ the results into<br>
the individual commit messages. If someone will review the change in a few<br>
years down the road and cannot find this website, how should he figure out<br>
whether this is still applicable? Or if one wants to come up with some<br>
improvements, one needs documentation on how to do that. Mixing email, blog<br>
and commit messages is not a good idea. The commit message should be self<br>
consistent.<br><br></blockquote><div>I did say that in this thread. Actually in one of the first lines of this thread:</div><div><br></div><div>quote:</div><div><span style="font-size:12.8000001907349px">-- The end result is a faster UDSEntry in every way. The benchmark results (which are from udsentrybenchmark) can be found here: </span><a href="http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=c936cdced4" target="_blank" style="font-size:12.8000001907349px">http://kdeblog.mageprojects.com/?p=394&preview=1&_ppp=c936cdced4</a><br></div><div><br></div><div>Note the part:</div><div>"<span style="font-size:12.8000001907349px">The benchmark results (which are from udsentrybenchmark)</span>"</div><div><br></div><div>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.</div><div><br></div><div>But you're right. I could have been a bit more verbose.</div></div></div></div>