Potential optimisation - fix a memory hole

[AnyOldName3]

I just took a look at the memory layout for vsg::VertexDraw because of something I was doing in a subclass, and realised that vsg::Object and every class that derives from it has a four-byte memory hole. In the case of vsg::VertexDraw in particular, it's got two of them as it's got five uint32_t fields followed by fields with eight-byte alignment. If the reference count and auxiliary pointer in vsg::Object were swapped, then the first uint32_t could slot in after the reference count and the class would be eight bytes smaller. Obviously, that'd be an improvement for cache hit rates, and it seems like a fairly low-risk change considering how many vsg::Object subclasses it's likely to compact.

[AnyOldName3]

I forgot the screenshot. Here it is:

[robertosfield]

Definitely worth trying swapping the order. The internal nodes of the scene graph will be the most sensitive to optimization.

Another approach might be to play tricks with the auxiliary pointer so it's only 32bit, but this would add some extra work when de-referencing the auxiliary pointer, how the auxiliary objects tend to be rarely used and accessed. However, cutting the vsg::Object size from 24 to 16 bytes would benefit all nodes in the scene graph, including those internal scene graph nodes that get hammered most during traversal.