Review Request 118265: Cache the top-level context associated with a QML module name

Denis Steckelmacher steckdenis at yahoo.fr
Thu May 22 20:43:52 UTC 2014



> On May 22, 2014, 8:08 p.m., Sven Brauch wrote:
> > 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? ;)

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


- Denis


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118265/#review58330
-----------------------------------------------------------


On May 22, 2014, 7:28 p.m., Denis Steckelmacher wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118265/
> -----------------------------------------------------------
> 
> (Updated May 22, 2014, 7:28 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-qmljs
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   duchain/parsesession.h 0222d72 
>   duchain/parsesession.cpp 798de10 
> 
> Diff: https://git.reviewboard.kde.org/r/118265/diff/
> 
> 
> Testing
> -------
> 
> 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).
> 
> 
> Thanks,
> 
> Denis Steckelmacher
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140522/ce59ea2a/attachment.html>


More information about the KDevelop-devel mailing list