[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BDW-GC] Static cell/string/symbol allocation
From: |
Ludovic Courtès |
Subject: |
Re: [BDW-GC] Static cell/string/symbol allocation |
Date: |
Tue, 13 Jan 2009 01:34:27 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
Hi!
address@hidden (Ludovic Courtès) writes:
> I modified <snarf.h> in the BDW-GC branch to transparently have all
> `SCM_SYMBOL ()' invocations use a statically allocated stringbuf. The
> symbol itself still has to be interned then so for simplicity the
> implementation statically allocates an immutable string and then uses
> `string->symbol' at initialization time to create an interned symbol
> (which reuses the string's stringbuf).
Here's an estimate of how much memory ends up being statically allocated
for libguile itself:
$ cat libguile/*.c | grep -e 'SCM_\(GLOBAL_\)\?SYMBOL' | \
sed s'/SCM_\(GLOBAL_\)\?SYMBOL[[:blank:]]*([^,]\+, "\([^"]\+\)".*$/\2/g' \
|wc -c
2921
This is the number of bytes of all the raw ASCII strings that make up
the symbols.
$ cat libguile/*.c | grep -e 'SCM_\(GLOBAL_\)\?SYMBOL' | \
sed s'/SCM_\(GLOBAL_\)\?SYMBOL[[:blank:]]*([^,]\+, "\([^"]\+\)".*$/\2/g' \
|wc -l
181
This is the number of symbols. Since we have two double-cells (on a
32-bit arch, each double-cell is 4 * 4 = 16 byte-long) per symbol (one
for the stringbuf and one for the string), we end up statically
allocating 2921 + (16 * 181) = 5817 B. OTOH, since we use
`string->symbol', we still have to allocate another 16 * 181 = 2896 B
worth of double-cells (for the symbols) so the "savings" are just
2921 B, i.e., 2921 B that are statically allocated instead of
dynamically (and they are shared, since they are read-only). Producing
directly statically-allocated writable uninterned symbols would help
here.
We could apply the technique to the 1001 subrs (~16 KiB of
double-cells), but these still have to be initialized at run-time. So
it looks like there isn't so much to be gained here. Comments?
Thanks,
Ludo'.