[antiloper]

I don't believe it.

Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.

[electroly]

I'm not disagreeing, but I will point out that COM reference counting is an atomic integer operation. That's expensive. boost::local_shared_ptr exists because std::shared_ptr does sometimes cause performance problems. std::shared_ptr must be used sparingly. It's unlikely to matter in a UI scenario with long-lived objects because it, indeed, does use reference counting sparingly.

[nxobject]

For that matter, AppKit was first released on a NeXT with a 25 MHz 68030 and 8MB of RAM.

[pjmlp]

Yes, and it doesn't do COM style reference counting to the level like WinUI does, so the point being?

My graduation thesis was porting NeXT software to Windows 95, no need for heads up.

[pjmlp]

Of course they cause problems as well, you not believing it doesn't change profiler facts.

I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.

[antiloper]

Can I see the profiler data that shows AddRef/Release being a performance bottleneck?

[pjmlp]

Yes, learn to use one and point it to a C++ Github project full of shared pointers.

[coffeeaddict1]

While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.

I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).

[pjmlp]

Which of those GUIs have you used where everything was a COM element?

[CJefferson]

I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.

[antiloper]

embarrassing