enforce()?

[Steven Schveighoffer]

On Mon, 19 Jul 2010 16:24:04 -0400, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Steven Schveighoffer:
>> What's so horrible about it?
>
> Using about 210% of the RAM I was planning to use. And not even saying  
> it in a small print somewhere in the docs.
>
>
>> It's a corner case.
>
> 4-word structs are quite common. It's not a common corner.

You mean it *is* a common corner?  I agree, and I think the bug report is  
warranted, we should get it fixed.  But again, you have specifically  
designed your input to thwart the system.  Those examples will always be  
possible to construct, unless you have a perfect memory allocator, which  
probably will be so slow that it's unusable.

>
>
>> 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.
>
> That is too much inefficient.

That is the cost of allocation schemes that use fixed size memory blocks.   
Especially when they grow in powers of 2.  Tune your app for it, and you  
won't have this problem.

>
>
>> 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.
>
> The allocator can have some overhead, but this is offensive.

I guess my answer is, tune your app to the allocator.  If you allocate a  
lot of little items, you will go a long way to allocate by allocating an  
array of them instead and use a free list.

>
>
>>  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.
>
> I have written plenty code in C and its cost is not that high.

So C does not use pools of fixed-size memory?  All its blocks it hands out  
are exactly the size you ask for?

Hm... let me test...

Yep, C does the same thing.  I wrote a small program to allocate 1,000,000  
blocks of a command-line-supplied size.

Up to 12 bytes per block allocates 17MiB, even if the blocks I request are  
1 byte.  For a single pointer, that's 300% overhead.  How horrid, let's  
lambaste the C allocator developers.  WHERE'S THE FINE PRINT!????

16 bytes per block allocates 24.6MiB.  Wait, shouldn't it be 17, surely  
that holds 16MiB of data?  What's going on here?  How can anyone be asked  
to deal with this shit?  Oh wait, I didn't *tune my app for the allocator*.

Above that, the C allocator does a good job of minimizing overhead, but  
that's for a plastic example of simply calling malloc 1M times in a row.   
And C has less to worry about than D when it comes to memory allocation  
and is far more experienced at it.  But it's not perfect in all  
situations.  It's much easier to tune your app to the allocator than tune  
the allocator to your app.

>
> I have seen you have changed my bug report, the first I have signed as  
> 'major' into an 'enhancement'. And you have said:
>> DMD functions exactly as designed.
>
> Then I can answer it's a *design* bug. I feel offended.

A design bug *is* an enhancement :)

-Steve