[Top][All Lists]

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

Re: Guile + Boehm GC: First Remarks

From: Ludovic Courtès
Subject: Re: Guile + Boehm GC: First Remarks
Date: Mon, 16 Oct 2006 09:46:06 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Hi Han-Wen,

Han-Wen Nienhuys <address@hidden> writes:

> Ludovic Courtès schreef:
>> But please, relax about performance, we still haven't run any meaningful
>> benchmark.  ;-)
> btw, is there any news on this patch?  I'm quite keen on dumping
> LilyPond's Rational class in favor of Scheme rationals, but adding gc
> mark functions for that is just too much work; BGC would be a nice
> soluiton to this.

Well, no real news.  My "not-so-meaningful benchmarks" (running a
loop[*]) reproductively show that "GBGC" is noticeably slower than "real
Guile" (1.5 to 2 times slower).

This could be due to various reasons.

* It could be that too much memory is being retained and subsequently
  scanned.  That's what I initially thought but after looking for this
  kind of error for some time, I'm not so convinced that this is the

* Initially, a fair amount of pointer-less memory (e.g., file or string
  contents) ended up being scanned.  I fixed this at some point, and now
  I don't think there's any such error left.

* The GC settings should be tweaked.  For instance, increasing BGC's
  initial heap size (e.g., via the `GC_INITIAL_HEAP_SIZE' environment
  variable) yields a noticeable improvement (though not sufficient).

* Any other reason listed (or not listed ;-)) at .

At this point, I'm a bit clueless not (yet) completely hopeless.  ;-)
That is, I think it'd be worth keeping investigating this, but I'm
definitely looking for people with a fresh view on the topic to help!

I recently merged in changes from HEAD in my BGC branch.  If you want to
give it a try and if you want to help, you can fetch it this way:

  $ tla register-archive
  $ tla get address@hidden/guile-core--boehm-gc--1.9


[*] It turns out that even tail-recursive call trigger memory
    allocation, via `SCM_EXTEND_ENV ()'.

reply via email to

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