Re: Unnecessary struct padding
Re: Unnecessary struct padding
- Subject: Re: Unnecessary struct padding
- From: Benjamin Rister <email@hidden>
- Date: Mon, 22 Aug 2011 23:34:47 -0400
Thanks for everybody's responses! It sounds like I don't really have a choice but to use #pragma pack and just be careful not to screw anything's alignment up. It's fun to do this kind of nitpicky optimization, but the cost in fragility is unfortunate (and it's so rarely beneficial anyway).
A couple additional responses below.
Tom Seddon wrote:
> I would have expected that this requirement could be relaxed for unnamed struct types - certainly looks like it could be in this case. Perhaps there's some subtlety that prevents this. Or maybe it's just not implemented.
Yes, this is what surprised me about this. I'd totally get it if the overall struct got padded to 8 bytes because it might be made into an array somewhere, but considering the compiler already knows what's coming after that sub-struct 100% of the time, there's no reason for that padding.
It seems that a minimal attempt to be more efficient with this could pay off fairly well across all of the various structs compiled on the whole system, so it's strange that it's not implemented.
Wim Lewis wrote:
> I think you can save some space in your declaration by flattening it from struct{union{struct{union}}} to simply struct{union{struct}}, duplicating the common fields in each union member.
I'm having trouble wrapping my head around this one. My sense is that this would only be feasible if it was the same property that determined which of the union fields were meaningful for both the outer and the inner unions. Considering the two inner unions are different sizes, and are decided on separately from what's used to choose in the outer union, I'm not seeing a way that I could promote them outward. Let me know if I'm missing something!
> If most instances of this structure use the smaller union members, you might also gain by moving the other fields into a completely separate array, tree, or hashtable which can store the sparse population of larger values efficiently.
Yeah, I'm playing those kinds of games too. Some fields also almost always have the same value, so I'm yanking those out into a separate table and using the default for anything missing from the table.
Best,
br _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden