[cfe-dev] Clang tool optimizations for performance?

William Ledoux william.ledoux at gmail.com
Thu Dec 5 10:21:54 PST 2013


Hi,

I have the same question over here.

Our test case cpp file of 1400 lines with a bunch of includes, resulting in
138 000 lines after preprocessing. parseTranslationUnit takes *1.6 sec* for
this translation unit with CXTranslationUnit_PrecompiledPreamble flag only.

Afterward, on the same bench, the first call to reparseTranslationUnit is
even slower* (3 sec)*, but,
each of the following calls to reparseTranslationUnit take only *0.4 sec*.

We were wondering why we can't tell which files have or haven't changed
since the last reparse (can we ?).

The only app that I know of that seems to colorize after each keystroke is
XCode.
I wonder if they use libclang or a lower level api, or an in-house
solution, or a mix, and what are the optimizations that were required.

Does anyone know of an open source project that uses clang for syntax
highlighting ( aside the abandonned project SourceCodeKit ) ?

Best Regards,
William


On Thu, Dec 5, 2013 at 3:27 PM, Anton Smirnov <dev at antonsmirnov.name> wrote:

> Hi.
>
> My tool (smth like IDE) uses Clang via C API. The main approach is the
> next, when the file is changed:
>
>    1. parseTranslationUnit
>    2. getDiagnosticSetFromTU
>    3. tokenize
>    4. indexSourceFile
>
> This makes all the features (highlighting, building file structure tree,
> diagnostics) working perfect, but it takes a lot of time as it's working on
> mobile device.
>
> I will do obvious optimization - executing in worker thread in order to
> avoid UI blocking, but i'd like to know about other optimizations.
>
> What can be done concurrently in order to get better performance (lower
> response time)? Is it safe to perform actions after parsing concurrently?
> Any other optimizations? Also i use a lot of libraries using '-I' arguments
> in commandLineArgs for parse() and index(). Is there any approach to avoid
> reparsing them each time user file is changed?
>
> Regards, Anton.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131205/f98c9cba/attachment.html>


More information about the cfe-dev mailing list