<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/118265/">https://git.reviewboard.kde.org/r/118265/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On May 22nd, 2014, 8:08 p.m. UTC, <b>Sven Brauch</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Sorry for being a bit unclear, I actually only meant it *could* potentially be slow if it does a dozen stats per parsed file. Did you do a test if it actually *is* slow? ;)</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">If I run the unit tests under strace, I can see that there is one stat() call each time an import is parsed, and several access() calls. The stat() call points directly to the correct file, so KStandardDirs seems to be highly optimized and to do its own caching (maybe even in ksycoca), but there are still access calls. This should not be too slow, but maybe a bit of caching can help on slow computers.
Here is the filtered output of strace:
# First parse of an import statement, KStandardDirs does not know where is the file
[pid 13075] read(17, "import QtQuick 1.1\n\n/**\n * \"toSt"..., 16384) = 716
[pid 13075] access("/home/steckdenis/.kde-unit-test/share/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", R_OK) = -1 ENOENT (No such file or directory)
[pid 13075] access("/usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", R_OK) = 0
[pid 13075] stat("/usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", {st_mode=S_IFREG|0644, st_size=147366, ...}) = 0
[pid 13074] stat("/usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", {st_mode=S_IFREG|0644, st_size=147366, ...}) = 0
[pid 13074] open("/usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", O_RDONLY|O_CLOEXEC) = 17
# QtQuick.tooling is not exported by Qt, so no file can be found
[pid 13074] read(17, "import QtQuick.tooling 1.1\n\n// T"..., 147366) = 147366
[pid 13074] stat("file:///usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", 0x7f77cbffe6f0) = -1 ENOENT (No such file or directory)
[pid 13074] access("/home/steckdenis/.kde-unit-test/share/apps/kdevqmljssupport/qmlplugins/QtQuick.tooling.qml", R_OK) = -1 ENOENT (No such file or directory)
[pid 13074] access("/usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.tooling.qml", R_OK) = -1 ENOENT (No such file or directory)
# Second parse of an import statement. As KDevelop has already parsed the file, it does not reopen it, thus saving a stat() and an open() call.
[pid 13075] read(17, "import QtQuick 1.1\n\n/**\n * \"toSt"..., 16384) = 716
[pid 13075] access("/home/steckdenis/.kde-unit-test/share/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", R_OK) = -1 ENOENT (No such file or directory)
[pid 13075] access("/usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", R_OK) = 0
[pid 13075] stat("/usr/share/kde4/apps/kdevqmljssupport/qmlplugins/QtQuick.qml", {st_mode=S_IFREG|0644, st_size=147366, ...}) = 0</pre>
<br />
<p>- Denis</p>
<br />
<p>On May 22nd, 2014, 7:28 p.m. UTC, Denis Steckelmacher wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDevelop.</div>
<div>By Denis Steckelmacher.</div>
<p style="color: grey;"><i>Updated May 22, 2014, 7:28 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdev-qmljs
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">As pointed out by Sven Brauch, KStandardDirs::findResource can be slow (it has to access the file system). This patch caches in the parse session the top-level context of every referenced module. This way, when the user types and the same parse session is reused over and over again to update the DUChain, the filesystem is not touched.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">All the unit tests still pass, and the behavior of import statements is as before (maybe a bit quicker, but it may be an impression).</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>duchain/parsesession.h <span style="color: grey">(0222d72)</span></li>
<li>duchain/parsesession.cpp <span style="color: grey">(798de10)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/118265/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>