Review Request 124249: Greatly improve include-path completion performance

Milian Wolff mail at milianw.de
Mon Jul 6 12:50:07 UTC 2015


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


in principle +1, but have you double-checked that this does not introduce any race condition? What happens when one thread sets the environment and another reads it - is this really not possible? I think you'll have to lock the mutex before returning the environment, to prevent this issue. As we return by value, this should then be thread-safe.


duchain/parsesession.h (line 70)
<https://git.reviewboard.kde.org/r/124249/#comment56427>

    make the function const, not the returned environment.


- Milian Wolff


On July 4, 2015, 9:45 a.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124249/
> -----------------------------------------------------------
> 
> (Updated July 4, 2015, 9:45 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdev-clang
> 
> 
> Description
> -------
> 
> Clang reparses a document without using PCH internally when editing file's preamble. This is very slow. So instead of locking ParseSession to prevent concurrent access to CXTranslationUnit (which include-path completion doesn't use), let's make ClangParsingEnvironment directly accessible through the session data.
> 
> 
> Diffs
> -----
> 
>   codecompletion/includepathcompletioncontext.cpp 34f613b 
>   duchain/parsesession.h 74999de 
>   duchain/parsesession.cpp cfafa33 
> 
> Diff: https://git.reviewboard.kde.org/r/124249/diff/
> 
> 
> Testing
> -------
> 
> I've been using this patch for more than a week. No side effects so far.
> 
> 
> Thanks,
> 
> Sergey Kalinichev
> 
>

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


More information about the KDevelop-devel mailing list