while looking at a tool that uses clang-c to parse a lot of files in GDB, I
noticed that every call to clang_parseTranslationUnit triggers a call to
#0 0x00007fe4fa0cc2d4 in pthread_create@@GLIBC_2.2.5 () from
#1 0x00007fe44e2fc630 in llvm::llvm_execute_on_thread(void (*)(void*), void*,
unsigned int) () from /usr/lib/libLLVM-3.4.so
#2 0x00007fe44e2d8e53 in llvm::CrashRecoveryContext::RunSafelyOnThread(void
(*)(void*), void*, unsigned int) ()
#3 0x00007fe44f34a293 in clang_parseTranslationUnit () from
Would it not be better, performance-wise, to recycle the threads in a thread
I'm using clang 3.4 btw.
This certainly could give us some speedup. How much does
pthread_create() cost on your system?
Based on the simple attached example, the benefit is pretty small. I.e., on my
machine the reusable thread runs the test in ~1.9s, while the iterative
approach takes ~5.2s.
That is a cost saving of only ~3s over a run of 100000 iterations. Considering
that the workload in clang is much higher, I doubt the time savings will be
noticeable. The only thing that will be noticeable, is one from the tooling
perspective: You don't see threads being created and deleted all the time
(esp. in GDB).
But I could understand if this is not worth the extra code required to reuse a
test.cpp (2.83 KB)
This amounts to 30 us for a single run. I guess, every little bit
helps. We would accept the patch to implement a portable thread pool
in libSupport and use it in libclang, but I don't think this is
high-priority for someone to work on.