[llvm-dev] IntrusiveRefCntPtr vs std::shared_ptr

[Benjamin Kramer via llvm-dev]

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::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code.
> Due to better performance?
>
>
> for example in main func of clang frontend:
>
> int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) {
>   ensureSufficientStack();
>
>   std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());
>   IntrusiveRefCntPtr<DiagnosticIDs> DiagID(new DiagnosticIDs());
>
>   IntrusiveRefCntPtr<DiagnosticOptions> 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