[Development] std::allocate_shared for QSharedPointer

[Sean Harmer]

Hi Thiago,

On Saturday, 9 September 2017 14:37:00 BST Thiago Macieira wrote:
> On Saturday, 9 September 2017 05:46:49 -03 Sean Harmer wrote:
> > Does anybody have any plans to add such a facility? Or is there some
> > other facility to avoid operator new here for both the QSP and the
> > object itself?
> 
> There are no plans. We don't have allocators anywhere in Qt, so I doubt this
> will ever happen.
> 
> > The QSharedPointers are used in the public API as we can't use
> > std::shared_ptr there. I guess the closest I can get without such a
> > facility is to maintain a pool of QSharedPointers, a pool of the objects
> > and use QSharedPointer::reset() when recycling or just keep the two pools
> > in sync whcih I guess makes sense anyway.
> 
> That won't help:
> 
>     inline void reset(T *t)
>     { QSharedPointer copy(t); swap(copy); }
> 
> Have you benchmarked and found out that the malloc() for the
> QtSharedPointer::ExternalRefCountData pointer is the culprit?

Yes, vtune shows the line

static_cast<ExternalRefCountWithContiguousData *>(::operator 
new(sizeof(ExternalRefCountWithContiguousData)));

is the bottleneck in this particular test case, qt3d/tests/manual/bigscene-
cpp. I maybe able to reduce the calls to this by a small constant factor but 
I'm not sure yet, need to do some more digging/experimenting. So using a pool 
seemed like a viable approach to reducing this bottleneck.

Granted, this is an extreme stress test (1k QEntities, each with 2 x 
QPropertyAnimations) but it makes a nice one to profile.

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions