[cfe-dev] LLVM, Clang Development IDEs

[Vladimir Voskresensky - Oracle via cfe-dev]

On 09/14/15 09:08 PM, Manuel Klimek via cfe-dev wrote:
>
>>
>>     I guess the answer to my questions is "no",
>     The answer to your original question
>     "Will this by any chance use the compilation database integration?"
>     is "no"
>     Because we have all this information already. We don't need clang for that
>     task.
>     We generate compilation database for any arbitrary complex systems by own
>     mechanism.
>
>
> Well, the problem is once you hit a single highly integrated codebase of > 
> 100MLOC on networked file systems (meaning latency at least 1 order of 
> magnitude higher than local disk) most of the IDEs I've tried fail miserably.
That's why I'm also very interested in the try.
>
>     But we can read compile_commands.json format as well and use it to
>     configure NetBeans (and in 8.1 we use it to init Clang classes).
>
>
> If I put O(500k) files into it, many of which take 20-60 seconds to parse, 
> what will happen?
I think it would be O(TIME): where TIME is
#time find $SOURCE_ROOT -name "*.h" -o -name "*.cpp" -o -name "*.c" | xargs  cat 
| wc -l

Btw, where have you got 20-60 seconds timing per compilation unit? From clang++?

This is example for Mozilla code base:
#export SOURCE_ROOT=/export/devarea/osprojects/mozilla-central
#time find $SOURCE_ROOT -name "*.h" -o -name "*.cpp" -o -name "*.c" | xargs  cat 
| wc -l
  8 050 831
real *1m22.518s*
user    0m1.978s
sys    0m4.635s

This is the internal statistics printed by NetBeans:
Compilation Units:    5587
=== Stopping parser queue stopwatch mozilla-central (14745 files):      127953 ms
Parsed 6521 KLines, Time *128* seconds, Speed 50 KLines/second, Max Memory 5064 Mb

This is on Solaris with 4cores x 4Gz machine with
#netbeans -J-Xmx6G

>>     then - what I really want to do is be able to use the already existing
>>     integration we have for our internal build system with clang tools via
>>     the compilation-database to use NetBeans, but from what you say it seems
>>     like that's not possible.
>     If "existing integration you have for your internal build system" can dump
>     cmake-complaint compile_commands.json, then you can use NetBeans.
>
>
> See questions above.
>
>     If you are really interested in trying NB[1] then let's exclude cfe-dev?
>
>
> I'm interested in using NB, but I'd also first like to understand some of the 
> engineering trade-offs you made - as the maintainer for our tooling 
> infrastructure in clang, I'd like to get to a point where we get a lot of 
> integration for free, instead of everybody needing to re-invent the wheel 
> because we don't meet the requirements.
What we had to made as tradeoff: Parse headers "minimal amount of times"
So, we have introduced smth like "chained PCHs" long time ago.
It allows to reuse what was parsed in the context of one translation unit for 
parsing other translation units if "controling macro" for header check says "ok" 
to reuse (so, one header sometimes has several versions of PCH states)

Of course I would recommend to run NB (being Java app) to allow big heap 
allocation, i.e.
#netbeans -J-Xmx6G

Thanks,
Vladimir.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150916/853c5a60/attachment.html>