chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] [PATCH] Reduce silly & needless scratch space allocati


From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Reduce silly & needless scratch space allocation when reading numbers
Date: Thu, 9 Mar 2017 21:54:13 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

Hi all,

I was debugging something entirely different the other day, and while
doing so I used the -:d switch, and saw my entire terminal fill up with
messages like this:

[debug] resizing scratchspace dynamically from 0k to 2k ...
[debug] resizing scratchspace dynamically from 2k to 2k ...
[debug] resizing scratchspace dynamically from 2k to 2k ...
[debug] resizing scratchspace dynamically from 0k to 2k ...
[debug] resizing scratchspace dynamically from 2k to 2k ...
[debug] resizing scratchspace dynamically from 2k to 2k ...
[debug] resizing scratchspace dynamically from 0k to 2k ...
[debug] resizing scratchspace dynamically from 2k to 2k ...
[debug] resizing scratchspace dynamically from 2k to 2k ...

This is stupid, and I quickly determined that this must be some
piece of code that was written to be simple, being so lazy as
to _always_ pre-allocate a bignum even if the number wasn't so
big (as my code wasn't using bignums at all).

As it's a design goal to avoid even _having_ a scratchspace when
bignums are not being used, this is obviously a bug.  But it's
also a performance penalty, because each of those lines above
correspond to a malloc() being done, and there's also a corresponding
free().

The bug turned out to be in the C_s_a_i_digits_to_integer, the C helper
function that string->number uses to convert a string of digits to an
integer.  This is only ever used in two places in string->number, so
this is easily fixed by allocating a little bit more than necessary
for a bignum wrapper, and using that extra memory to fit a small bignum
into the nursery.  This space won't be used if the pre-allocated bignum
needs to be bigger, but in the vast majority of cases it's just a fixnum
that we're reading, so this should be a pretty big win.

In a few quick benchmarks it doesn't seem to make a difference (I guess
malloc just keeps reusing the same block), but at least it stops the
resizing scratchspace spam :)

Cheers,
Peter

Attachment: 0001-Avoid-allocating-scratchspace-when-reading-fixnums.patch
Description: Text Data

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]