From: hanwen@byrd.xs4all.nl (Han-Wen Nienhuys)
Subject: Re: GC improvements
Date: Fri, 23 Dec 2005 11:29:57 +0000 (UTC) [thread overview]
Message-ID: <dogn3l$cv0$3@sea.gmane.org> (raw)
In-Reply-To: 87slsnk9u0.fsf@laas.fr
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
In article <87slsnk9u0.fsf@laas.fr>,
Ludovic Courtès <ludovic.courtes@laas.fr> 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 the end of the program. Thus, intuitively, one might say
>that there is nothing to collect in this program, so no need to
>mark/sweep all the time.
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.
>Therefore, my question is: how can we improve on this?
>
>As I understand it, generational GC could help solve this. However,
>being unfamiliar with this, I fail to see how this could be integrated,
>and how much work is required.
For startup time, I think the best (as in: quickest) would be undump a
previous run, instead of recalculating all the initialization on every
run. Not only does this save on GC time, it also bypasses all evaluation.
Isn't this what Emacs also does?
Personally, I think it is much more interesting to optimize for
efficiency on longer projects.
BTW, I propose that the GC yields are changed a bit. I've heard other
people comment that GUILE is dead slow compared to PLT Scheme. I've
investigated with one Boehm's GC benchmarks, and for this case it
turns out that increasing GC minimum yields sped GUILE up by a factor
1.5 or so.
Han-Wen
P.S. what's keeping back the GUILE 1.8 release?
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2005-12-23 11:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-20 16:32 GC improvements Ludovic Courtès
2005-12-23 11:29 ` Han-Wen Nienhuys [this message]
2005-12-23 15:40 ` 1.8 [was: GC improvements] Andy Wingo
2005-12-24 0:59 ` 1.8 Kevin Ryde
2006-01-03 10:16 ` GC improvements Ludovic Courtès
2006-01-04 1:03 ` Han-Wen Nienhuys
2006-01-04 16:18 ` Ludovic Courtès
2006-01-05 14:47 ` Ludovic Courtès
2006-01-06 20:22 ` Han-Wen Nienhuys
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='dogn3l$cv0$3@sea.gmane.org' \
--to=hanwen@byrd.xs4all.nl \
--cc=hanwen@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).