unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludovic.courtes@laas.fr (Ludovic Courtès)
Subject: GC improvements
Date: Tue, 20 Dec 2005 17:32:55 +0100	[thread overview]
Message-ID: <87slsnk9u0.fsf@laas.fr> (raw)

Hi,

I did some profiling with the workload I described earlier[0].

When using the three patches I sent recently[*], around 35% of the
execution time is spent in memory management:

   %   cumulative   self              self     total           
  time   seconds   seconds    calls   s/call   s/call  name    
  28.10     16.63    16.63    41385     0.00     0.00  ceval
  18.02     27.29    10.66    32399     0.00     0.00  scm_i_sweep_card
   8.54     32.34     5.06  4729114     0.00     0.00  scm_cell
   5.11     35.37     3.03  2737955     0.00     0.00  scm_ilookup
   3.23     37.28     1.91     7086     0.00     0.00  scm_i_init_card_freelist
   2.96     39.03     1.75   383266     0.00     0.00  scm_gc_mark_dependencies
   2.64     40.59     1.56      657     0.00     0.01  scm_i_mark_weak_vector_non_weak

Commenting out explicit calls to `scm_gc ()' and `scm_i_gc ()' doesn't
make a big difference.

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.

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.

Thanks,
Ludovic.

[0] http://lists.gnu.org/archive/html/guile-devel/2005-12/msg00093.html

[*] Improved `scm_from_locale_symbol ()' + `guile-reader', fixed
    FREE_COUNT in `scm_i_sweep_card ()', fixed CELLS_COLLECTED in
    `scm_i_sweep_some_cards ()')


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


             reply	other threads:[~2005-12-20 16:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-20 16:32 Ludovic Courtès [this message]
2005-12-23 11:29 ` GC improvements Han-Wen Nienhuys
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=87slsnk9u0.fsf@laas.fr \
    --to=ludovic.courtes@laas.fr \
    /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).