On Mon, 19 Jul 2010 15:53:46 -0400, bearophile <[email protected]>
wrote:
Steven Schveighoffer:
Not quite :) There is one byte for padding because (insert
gasp-inspiring
music accent) all struct heap allocations are allocated through newArray
with a size of 1. I discovered this when working on the array append
patch.
How much more hidden shit like this do I have to see?
I have filed a bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=4487
Maybe Walter has to fix this before porting dmd to 64 bits.
Most of this is mitigated if you have a custom allocator that allocates
an
array of nodes at once
The GC is supposed to not suck that much. If I want to do all manually
and use custom allocators then maybe it's better if I start to switc to
C language.
Thank you Steven.
What's so horrible about it? It's a corner case. If you were allocating
a 20-byte struct, you are wasting 12 bytes per value anyways. Or what
about a 36-byte struct?
All I'm saying is the pad byte itself isn't a huge issue, even if it
didn't exist, there would always be inefficient allocations. Take the
redblack tree node for instance. Get rid of the pad byte, and it's tuned
for word-size payload. But go over that, and you're back to pretty much
wasting 50% of your memory. If you want to tune your app to be the most
efficient at memory allocation, you need to study the allocator and learn
its tricks and nuances. I think you have some misguided notion that C's
allocator is perfect, and there's no hidden cost to it. That's not the
case.
That being said, it would be good if we could get rid of the 1-byte pad
for single struct allocations on the heap. As a bonus, the code will be
more efficient because it doesn't have to deal with the "array" notion.
-Steve
