[llvm-dev] IntrusiveRefCntPtr vs std::shared_ptr (original) (raw)

Benjamin Kramer via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 19 08:24:50 PDT 2016

In terms of performance shared_ptr has a number of disadvantages. One is that it always uses atomics even though most IntrusiveRefCntPtrs are used in single-threaded contexts. Another is weak_ptr adding a lot of complexity to the implementation, IntrusiveRefCntPtr doesn't support weak references.

With that it's hard to make a case for changing uses of IntrusiveRefCntPtr as it's a non-trivial amount of work (IntrusiveRefCntPtr binds the reference count to the object itself, shared_ptr doesn't. Figuring out when a value held by an IntrusiveRefCntPtr is passed around by raw pointer and stuffed into another IntrusiveRefCntPtr is hard) with potential negative performance impact.

On Wed, Oct 19, 2016 at 11:43 AM, Ivan Kush via llvm-dev <llvm-dev at lists.llvm.org> wrote:

why llvm contains IntrusiveRefCntPtr instead of using only std::sharedptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance?

for example in main func of clang frontend: int cc1main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::uniqueptr Clang(new CompilerInstance()); IntrusiveRefCntPtr DiagID(new DiagnosticIDs()); IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions(); -- Best wishes, Ivan Kush

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list