Comments on: Crunching bytes

By: Be nice to your cache | .mischief.mayhem.soap.

Be nice to your cache | .mischief.mayhem.soap. — Sun, 25 Apr 2010 15:36:23 +0000

[...] not bloat your structures. Think about padding (Cruncher# to the rescue!), use bitfields instead of multiple bools, consider using smaller data types. Of [...]

By: admin

admin — Mon, 29 Mar 2010 20:21:34 +0000

@Jumpster: that’s exactly right (= layout conclusions). With classes is exactly the same (the only difference in C++ is that class members are private by default, generated code is identical).
About the optimal structure suggestion — it’s probably a good idea, but problem is not trivial (variation of knapsack, basically), so it’s something I postponed until I have more free time.

By: Jumpster

Jumpster — Sat, 20 Mar 2010 00:11:12 +0000

Perhaps a future revision to Cruncher# may offer a *suggestion* of a new structure format that minimizes the padding requirements?

Just a suggestion, pretty cool program!

Me likey,
Jumpster

By: Jumpster

Jumpster — Fri, 19 Mar 2010 23:55:04 +0000

It took me a bit to envision what you are saying, but I get it now: Using your example;

struct one {
byte byte_1; // 3-bytes padding
int int_1;
byte byte_2;
byte byte_3;
byte byte_4; // 1-byte padding
}; // sizeof() = 12

struct two {
byte byte_1;
byte byte_2;
byte byte_3;
byte byte_4;
int int_1; // No padding
}; // sizeof() = 8 -> 33% savings…

I’m glad I stumbled upon your site. In all my years of programming, I never realized the inefficiencies caused by my data structures.

Just a question tho, although I could check this myself – but if you already know the answer… :)

Anyway, since classes and structs are essentially the same, then is it safe to assume class structures have the same types of inefficiencies?

I tend to place class definitions (methods/member vars/etc) in what I feel is a logical point, I assume that classes should be looked at too?

Anyway, thanks for the info. That was something I didn’t know.

Regards,
Jumpster

By: admin

admin — Wed, 17 Mar 2010 08:58:37 +0000

You understand it correctly. That’s why I don’t advocate using #pragma pack(1) (this would force 1-byte alignment and eliminate padding, the ‘easy’ way). Instead we want to minimize ‘holes’ caused by inefficient alignment. For example, if there’s a byte, followed by int, followed by 3 bytes, it’d be more effective to rearrange it so that 4 1-byte member go first, then goes integer. In real world cases it’s usually impossible to eliminate them completely, but I’ve been able to reduce size of important structures by ~10-15% just by shuffling variables around.

By: Jumpster

Jumpster — Wed, 17 Mar 2010 02:30:33 +0000

I realize I’m a bit late here, but I’m a bit confused…

I understand the reason for *saving* memory (ie: reduce memory padding to save resources) but I was under the impression that aligning structures to a native size (4-bytes on 32-bit systems / 8-bytes on 64-bit systems) improves efficiency due to the memory/cache access improvements? Am I misunderstanding something here?

Regards,
Jumpster

By: Structure Padding Analysis Tools | Rachels Lab Notes

Structure Padding Analysis Tools | Rachels Lab Notes — Thu, 22 Oct 2009 15:19:07 +0000

[...] yet, occasionally, something slips through. So it’s nice that somebody wrote a tool – Cruncher# – to just load your PDB and examine all your structures for unnecessary [...]

By: Arseny Kapoulkine

Arseny Kapoulkine — Tue, 15 Sep 2009 18:37:14 +0000

Remembered about this once again through Twitter link :) Got a msdia90.dll, registered it – now it works! I wonder if there’s an official way to do it (except installing MSVS 2008…).

By: admin

admin — Tue, 08 Sep 2009 21:27:18 +0000

Yes, that’s DIA. If I remember correctly I used msdia90.dll from latest Microsoft’s Debugging SDK. C# tends to act weirdly sometimes…

By: Arseny Kapoulkine

Arseny Kapoulkine — Tue, 08 Sep 2009 05:27:51 +0000

Installing VC2008 redist did not help; downloading and registering (via regsvr32) msdia80.dll did not help either.