guile-devel
[Top][All Lists]
Advanced

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

GC improvements


From: Ludovic Courtès
Subject: GC improvements
Date: Tue, 20 Dec 2005 17:32:55 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

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 ()')




reply via email to

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