On Wednesday 15 January 2014 13:42:01 Kuba Ober wrote: > Currently, the metacall arguments are marshaled by copy-constructing them in > their own heap blocks. The addresses to the copies are deposited in an > array-of-void*, passed as the args argument to QObject::qt_metacall etc. > > So there are two layers of allocations: > > 1. An array of void* is heap-allocated. > 2. It’s filled with pointers to heap-allocated copies of each argument. > > The void** args protocol can be preserved, but instead of allocating copies > on the heap, they could be in-place-constructed right after the pointers. > So args would be an array that has: > > pointer-to-return-value-instance > pointer-to-arg1-instance > … > pointer-to-argn-instance > nullptr > return-value-instance > arg1-instance > … > argn-instance > > If any of the pointers is zero, the instance would not be present in the > array (it will not occupy an instance space). > > The metatype system stores the size of types known to it, so it’s a simple > matter to know how big the all-in-one array needs to be, taking alignment > into consideration, of course. > > I don’t know yet if such a change would be binary compatible, that needs > further checking of course. Initially it looks as if it would be > compatible, since the QMetaCallEvent class is internal only, just as > queued_activate is etc. > > I would like to know if such a change would be considered useful. The > potential for underlying allocator global lock contention is much smaller, > besides not paying the uncontested lock allocation costs, and simply using > a bit less memory for every metacall event. > > As an extension of this approach, one could provide a factory method in > `QMetaCallEvent` that would allocate the proper amount of memory all in one > go (to fit the event, the arguments, and possibly the types when it owns > the types). > > Does this make sense?
Yes, it's a good idea. Note that you are only talking about queued connection here, because direct connection put the array on the stack. You could even add a QVarLenghtArray in QMetaCallEvent to hold the data. Notice that I noticed that sometimes, two small allocations are faster than a big allocation. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
