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

Sven Brauch svenbrauch at googlemail.com
Thu May 22 20:08:59 UTC 2014


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


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? ;)

- Sven Brauch


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/1b0dc469/attachment.html>


More information about the KDevelop-devel mailing list