Review Request 124249: Greatly improve include-path completion performance

[Milian Wolff]

> On July 6, 2015, 12:50 p.m., Milian Wolff wrote:
> > 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.
> 
> Sergey Kalinichev wrote:
>     The environment set only once in the ParseSessionData constructor. And setData in ParseSession simply exchanges pointers to the data, so it shouldn't be possible.

ok cool.


- Milian


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


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/20150712/66831f3f/attachment.html>