This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: New: SCM_DEBUG_CELL_ACCESSES
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: New: SCM_DEBUG_CELL_ACCESSES
- From: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 23 May 2000 15:36:31 +0300
- Cc: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>, Guile Mailing List <guile at sourceware dot cygnus dot com>
- Organization: who? me?
- References: <Pine.LNX.4.21.0005231147510.346-100000@marvin.ida.ing.tu-bs.de>
Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> - it seems that the checks for scm_heap_table[seg_id].valid != NULL are
> unnecessary, since that feature is not used. There's even a comment
> about it not being used at the head of gc.c. If we want to speed
> things up, unused features should be removed.
I too wonder what this thing supposed to be for.
> - The comments about span are wrong, IMO. It says, span is the "number of
> SCM words per object in this segment", but it rather seems to be the
> number of scm_cells per object: span is 1 most of the times.
I fixed the comment, thanks!
> However, for the sake of generalization it may be better to make
> span be the number of SCM/scm_bits_t words: This would even allow
> for cells with 3 entries etc.
what would 3-word (or 5-word) cells be useful for? (they are a bad
idea from the alignment and mark-bit space consumption points of view,
but still).
> - The initial number of stack frames when guile has started seems to be
> very large. As soon as the repl is reached, there are about 70 stack
> frames (with the debugging evaluator, I haven't checked the other
> one). Since the size of the stack defines the time for conservative
> stack scanning, continuation creation and calling, this is something
> that we also should try to reduce, if possible.
I doubt that continuations go that deep, but it's worth checking...
> I have instrumented the code of scm_mark_locations with counters to see
> the relative frequencies of the different execution paths.
very interesting. could you send your instrumentation so I can play
with it? or maybe even check it in, conditionally?
generally, I don't know if it's a good idea to try to minimize the
number of initial stack frames (it may distort the code too much), but
I do know that the `scm_cellp' logic could be a little streamlined
(the binary search could be replaced with two array lookups,
basically).
--
You have a tendency to feel you are superior to most computers.