Eric Blake <ebl...@redhat.com> writes: > The QObject hierarchy is small enough, and unlikely to grow further > (since we only use it to map to JSON and already cover all JSON > types), that we can simplify things by not tracking a separate > vtable, but just inline all two elements of the vtable QType > directly into QObject. We can drop qnull_destroy_obj() in the > process. > > This also has the nice benefit of moving the typename 'QType' > out of the way, so that the next patch can repurpose it for a > nicer name for 'qtype_code'. > > The various objects are now 8 bytes larger on 64-bit platforms, but > hopefully this is in the noise. If size is absolutely critical due > to cache line speed effects, we could do some bit packing to > restore the previous size (qtype_code currently only requires three > distinct bits, so we could assert an assumption that architecture > ABIs will give function pointers at least an 8-byte alignment, and > that the three low-order bits of destroy are always zero; or we > could use a bitfield for refcnt, with a maximum of SIZE_MAX/8, and > given that a QObject already occupies at least 8 bytes, that won't > artificially limit us). Or we could expose the currently static > destroy methods and instead create a table in qobject.h that maps > QType to destructor.
That's what I'd do. A type registration function would keep the destructors static. But why bother. > But let's save any size compression for a > followup patch, if at all. Okay. > On the other hand, by avoiding a separate vtable, there is less > indirection, so use of QObjects may be slightly more efficient. > > However, as we don't have evidence pointing at either QObject size > or access speed as being a hot spot, I didn't think it was worth > benchmarking. > > Suggested-by: Markus Armbruster <arm...@redhat.com> > Signed-off-by: Eric Blake <ebl...@redhat.com> Works for me.
