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