D memory consumption/runtime speed problem

Steven Schveighoffer schveiguy at yahoo.com
Thu Jan 14 05:53:51 PST 2010


On Thu, 14 Jan 2010 01:00:31 -0500, Daniel Keep  
<daniel.keep.lists at gmail.com> wrote:

>
>
> sybrandy wrote:
>> Hello,
>>
>> I've been writing a bit of compression code and I noticed some strange
>> behavior that's driving me a bit batty.  I don't know if it's a bug with
>> D or something I did.  All I know is I can't figure it out.
>>
>> ...
>>
>> Am I doing something wrong?  I've tried every trick that I could find by
>> reading the documentation.  Btw: The last time I tried this was with the
>> latest version of D released at the beginning of the month.
>
> I haven't verified this, but I'd be *deeply* suspicious of encodeNumber.
>  I don't usually use array literals but, if I remember correctly, every
> time it is called you're performing a heap allocation.  Even worse,
> those concatentations might be performing separate allocations, too.
>
> You could eliminate the overhead by using a passed-in buffer design like  
> so:
>
> ubyte[] encodeNumber(in uint count, ref ubyte[4] buffer)
> {
>     if (count <= ONE_BYTE_VAL)
>     {
>         buffer[0] = cast(ubyte)(ONE_BYTE_MASK | count);
>         return buffer[0..1];
>     }
>     // ...
> }
>
> Then, in the calling function:
>
> {
>     ubyte[4] temp;
>     foreach( ... )
>     {
>         appOutput.put(encodeNumber(count, temp));
>     }
> }
>
> See if that helps.

He's not using threads, you can simply do this in encode number:

static ubyte[4] buffer;

In fact, that might even work in D2 *with* threads since buffer would be  
thread local :)

-Steve


More information about the Digitalmars-d-learn mailing list