serge-sans-paille added a comment.
> Frontends not written in C++ will always be going through the
> AttributeKey::get() API, which will be slower than the initial state (I think
> -- we still have to calculate the hash dynamically, but now we also need to
> intern an AttributeKey by performing an actual hash table lookup.)
I ran the following benchmark
#include "llvm-c/Core.h"
int main() {
LLVMContextRef ctx = LLVMContextCreate();
LLVMAttributeRef Key = LLVMCreateStringAttribute(ctx, "mykey", 5,
"myvalue", 7);
unsigned size;
for(int i = 0; i <10000; ++i)
for(int j = 0; j <10000; ++j)
LLVMGetStringAttributeValue(Key, &size);
return size;
}
linking dynamically with libLLVMCore.so , the compiler doesn't optimize away
the loop content.
Before the patch: 0.39s , ~ 2.5G instructions
With the patch: 0.30s, ~2.3G instructions
Why is that so? A side effect of the patch is that srings are memoized into a
StringPool, so less allocation etc as soon as we lookup the attribute more than
once.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D114394/new/
https://reviews.llvm.org/D114394
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
