[cfe-dev] clang performance when building Linux
Benjamin Kramer
benny.kra at googlemail.com
Sat Apr 16 05:01:11 PDT 2011
On 13.04.2011, at 23:50, Török Edwin wrote:
> Hi,
>
> I did a performance profile of clang while building Linux kernel.
> The difference is not much compared to gcc, clang with asserts off is a
> bit faster than gcc, and with asserts on a bit slower.
>
> Here is the 'perf report' for clang with asserts off:
> https://gist.github.com/918497
> 3.65% clang clang [.] llvm::StringMapImpl::LookupBucketFor(llvm::StringRef)
I'm a bit surprised that StringMap is the most expensive entry here, maybe microoptimizing
the hash function (which is a byte-wise djb hash at the moment) can help a bit. If someone is
really bored it would also be useful to test if other string hash functions like murmurhash or google's
new city hash give better performance.
> 2.87% clang clang [.] clang::Lexer::LexTokenInternal(clang::Token&)
This is expected, the lexer usually dominates any C compiler's run time (well, except for crazy stuff like C++ ;),
clang's lexer is heavily optimized, I doubt we can improve much here.
> 2.74% clang [kernel.kallsyms] [k] clear_page_c
This is probably zero filling pages for malloc.
> 2.07% genksyms genksyms [.] yylex
> 1.88% clang clang [.] clang::SourceManager::getFileIDSlow(unsigned int) const
Despite that the name contains the word slow, this function is optimized well and known to be hot.
> 1.66% clang libc-2.13.so [.] _int_malloc
Reducing mallocs is an ongoing process, clang already pool allocates a lot of its data,
LLVM's types, constants and other stuff aren't allocated in pools at the moment but there are plans to fix that.
> 1.65% clang clang [.] clang::Lexer::LexIdentifier(clang::Token&, char const*)
> 1.08% clang libstdc++.so.6.0.15 [.] 0xa5750
> 1.08% clang clang [.] llvm::SmallPtrSetImpl::insert_imp(void const*)
> 1.07% clang clang [.] clang::TokenLexer::Lex(clang::Token&)
More information about the cfe-dev
mailing list