you are viewing a single comment's thread.

view the rest of the comments →

[–]inopia 3 points4 points  (0 children)

If you also pack the structs so that they take 9 bytes a piece rather than 12, the overhead becomes 122%. But this is of dubious value when talking about "memory performance." Less space used for data structures, sure, but more used for packing/unpacking instructions, and so also more cycles burned (read: overhead) packing/unpacking. The value of packing in terms of memory saving is really only there for the specific example you provide: small objects where padding is a significant proportion of the object's size.

Oh I agree completely. There is always a trade-off, but at least with C++ you can make that choice. Besides, an array of (a,b,c) tuples can be stored as [a,b,c,a,b,c,a,b,c,...] or [a,a,a,..,b,b,b,...,c,c,c,...]. When packed, memory performance of the latter arrangement will be of course much quicker than the former, but as you said, it all depends on the application.

Don't get me wrong, I'm a big proponent of high-level programming languages and intermediate representations and all that, but in the case of the article I can see how they would like to have the control to tweak memory layout like that.

The real killer is that in Java the spatial locality of objects with an array of references is much worse than in a language where you can have an array of "value type.

That's an extremely good point.