In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>> This interleaving of initialization and sweeping makes it pretty hard to
>> track exactly where fresh cells come from. I guess one solution might
>> be to maintain a list of the uninitialized segments and pick cells
>> d
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> This interleaving of initialization and sweeping makes it pretty hard to
> track exactly where fresh cells come from. I guess one solution might
> be to maintain a list of the uninitialized segments and pick cells
> directly from there before act
Hi Han-Wen,
Thanks for your input!
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> the easiest way is to modify
>
> scm_gc_for_newcell()
>
>
> so it directly passes to the
>
> scm_i_get_new_heap_segment (freelist, abort_on_error);
>
> case
No, that won't have any impact because this very cas
Ludovic Courtès wrote:
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
I think that GUILE creates garbage as a side effect of evaluating
code. If think that nothing needs to be swept, try disabling GC during
startup, and see how well it performs memory-wise.
I did try commenting out all calls
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> I think that GUILE creates garbage as a side effect of evaluating
> code. If think that nothing needs to be swept, try disabling GC during
> startup, and see how well it performs memory-wise.
I did try commenting out all calls to `scm_i_gc ()' and ru
In article <[EMAIL PROTECTED]>,
Ludovic Courtès <[EMAIL PROTECTED]> wrote:
>The workload I used is quite similar to what happens at startup time:
>new objects are created, new symbols are defined, and that's it. The
>symbols created (and even the numbers created) are expected to stay
>alive until
