Re: interpretation of gc results

From: Erick Gallesio <eg_at_unice.fr>
Date: Wed, 24 Mar 1999 12:13:56 +0100 (CET)

Brian Denheyer writes:
>
> here are some results from using the time function :
> <snip>
> ;; Time: 0.00ms
> ;; GC time: 0.00ms
> ;; Cells: 3877
> ;; Time: 16.67ms
> ;; GC time: 0.00ms
> ;; Cells: 4345
> ;; Time: 33.33ms
> ;; GC time: 0.00ms
> ;; Cells: 4813
> ;; Time: 83.33ms
> ;; GC time: 83.33ms
> ;; Cells: 5282
>
> What does the "Cells" entry mean ? Is it the number of cells currently
> in use or is it the number of cells which are collected by the GC
> after it runs ?

Neither one or two :^;
In fact this is the number of cells used by the computation of the
expression passed to time, and it doesn't take into account the fact
that there was, or not, a GC.

>
> ;; GC statistics
> ;; -------------
> ;; cells used 63331/80000
> ;; # of used heaps 1
> ;; # of GC calls 21 (time spent in GC 1383.33ms)
> (1 48082) (2 9) (4 1) (5 898) (6 44) (7 20) (8 180) (9 73) (10 12) (11 9) (12 17) (13 2) (14 19) (15 13) (16 15) (17 15) (18 232) (21 979) (22 10) (23 1) (24 1) (25 2) (26 2) (28 4) (31 2) (32 25) (33 540) (34 143) (37 8) (39 21) (40 2) (41 3) (42 5767) (45 560) (46 5609) (73 1) (74 1) (80 1) (90 8)
> ;;
>
> What do these pairs in the (gc-stat) results mean ? is there
> something there which might give me some insight into how my progam is
> working ?

Not really, In fact this is something that I should not let in
"production releases". For each list (a b), a is the type of the
object and b is the number of object of this type used . The
meaning of the type number can be inferred by reading the file
Src/stk.h (this is the tc_* definitions). For instance, your program
uses 48082 conses, 9 flonums, 1 bignum, ... when you called gc-stats.

>
> What I am seeing, in a program which uses a lot of consing, is that it
> slows down considerably as it runs. I am trying to figure out if it
> is the GC that is slowing it down or something else. Enlarging the
> heap definitely helps, but it still seems to bog down.
>
Yes of course, if you use a lot of cons, you will spend a lot of time
in the GC and increase the time used by your program.

> Is it possible that as GC runs the memory fragments and allocating new
> memory becomes a problem ?
>

It depends of what you are allocating. In fact the GC scheme used by
STk could lead to memory fragmentation in theory, but if you use only
conses this is not the case. A cell is a 3 words object. In fact cells
are pre-allocated and when a GC occurs:
        1. they are placed in a free list.
        2. if they points on "external" memory (i.e locations which
are not scheme objects), there is a C free which is done.

When you free a cons (which just contains 2 pointers on other
locations in the set of pre-allocated cells, there is no free). On the
contrary, if you free a cell which is a string descriptor, of course
the string itself will be freed.

So it is difficult to give you a general answer to thisquestion.

> Looking for insight on how to improve the running speed of this
> program. Unfortunately "un-consing" it's operation is not really an
> options since all of the operations are very dynamic and I don't
> really have an opportunity to allocate fixed length structures like
> vectors.

Yes but STk vectors are extensible, perhaps it could help (extension
potentially costs, but if this is rare, this could be a viable
alternative).



                -- Erick
Received on Wed Mar 24 1999 - 12:22:17 CET