<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Morten Volden</b> <span dir="ltr"><<a href="mailto:mvolden2@gmail.com">mvolden2@gmail.com</a>></span><br>Date: 2013/2/6<br>
Subject: Re: OutputModel performance<br>To: Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>><br><br><br><br><br><div class="gmail_quote"><div><div class="h5">2013/2/6 Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de" target="_blank">apaku@gmx.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div><br>
On Wed, Feb 6, 2013 at 4:59 PM, Kevin Funk <<a href="mailto:krf@gmx.de" target="_blank">krf@gmx.de</a>> wrote:<br>
</div><div><div>> On Wednesday 06 February 2013, 17:32, Alexander Shaduri wrote:<br>
>> Hello,<br>
>><br>
>> On Wed, 06 Feb 2013 13:25:17 +0100<br>
>><br>
>> Kevin Funk wrote:<br>
>> > I recently noticed that I get serious UI lockups when running a 'make<br>
>> > install' job inside KDevelop for larger projects such as kdelibs. 'make<br>
>> > install' here may produce roughly ~4500 lines of output in just a few<br>
>> > seconds.<br>
>> > ...<br>
>> > So, the question here:<br>
>> > - Did anyone of you guys experience similar issues just to begin with?<br>
>><br>
>> Just from the user's point of view:<br>
>> KDevelop is essentially unusable when I'm compiling my project (9 parallel<br>
>> make jobs). It seems that the outputview just cannot handle it quickly<br>
>> enough.<br>
>><br>
>> It's a typical cmake/Qt project compiled with make -j9, the full compilation<br>
>> takes about 30 seconds and produces ~500KB output (~2300 lines).<br>
>> CMAKE_VERBOSE_MAKEFILE is on.<br>
>><br>
>> If I set make jobs to 1 or CMAKE_VERBOSE_MAKEFILE to off, it's all fine.<br>
>><br>
>> I'd be grateful if you added this as a test case. Compiling, say, KDevelop<br>
>> with the same settings should give you the same drop in performance.<br>
>><br>
>> Thanks,<br>
>> Alexander<br>
><br>
> Just for the record -- I just measured the time it takes to complete<br>
> addLineBatch():<br>
><br>
> (...)<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  20 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  10 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  22 ms, processed lines: 2<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  8 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  8 ms, processed lines: 2<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  7 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  7 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  12 ms, processed lines: 3<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  9 ms, processed lines: 2<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  7 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  8 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  11 ms, processed lines: 4<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  7 ms, processed lines: 1<br>
> KDevelop::OutputModel::addLineBatch: elapsed time:  7 ms, processed lines: 1<br>
> (...)<br>
><br>
> IMO that clearly shows that this takes way too much processing time / line.<br>
<br>
</div></div>Well, unless you're using a high-precision timer I'm not sure how much<br>
you can trust those timings for a single line, it would be more<br>
interesting to see an average over 100 calls with the same<br>
(non-matching or matching) line or so. IIRC the code for matching is<br>
pretty much separate from the rest so it ought to be possible to<br>
writeup a test that does this which can then also be better<br>
valgrind'ed.<br></blockquote></div></div><div><br>I can see that I accidentally sent this to Andreas only - sorry about that.<br><br>A test like that already exists in outputmodeltest. It benchmarks the different output filtering strategies.<br>
<br>Here is a sample from a test I just ran:<br>QDEBUG : KDevelop::OutputModelTest::benchmarkAddlinesNofilter() average UI lockup in ms:  0.263682 <br>
QDEBUG : KDevelop::OutputModelTest::benchmarkAddlinesCompilerfilter() average UI lockup in ms:  8.64179 <br>QDEBUG : KDevelop::OutputModelTest::benchmarkAddlinesScriptErrorfilter() average UI lockup in ms:  1.36318 <br>QDEBUG : KDevelop::OutputModelTest::benchmarkAddlinesStaticAnalysisfilter() average UI lockup in ms:  0.228856 <br>

<br>Maybe if we got a sample of the compileoutput that seems to cause trouble, rewrote the test a little to feed each line to the matching code and do timing on matches. If one or more of the lines sticks out timing wise, it should be fairly simple to find the regex that performs badly on the line(s).<br>

<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Are callgrind files cross-platform? If so you could upload your data<br>
as well, so others can investigate this a bit already (I'm<br>
particularly interested in which Qt function all the time is spent,<br>
i.e. which is the biggest self-time function).<br>
<span><font color="#888888"><br>
Andreas<br>
</font></span><div><div>_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kde.org" target="_blank">KDevelop-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kdevelop-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br>- When the split is pulled, mr. Grenade is no longer our friend
</font></span></div><br><br clear="all"><br>-- <br>- When the split is pulled, mr. Grenade is no longer our friend