Re: Making Guile slower

[Greg Harvey <Greg dot Harvey at thezone dot net>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> I should have formulated it differently.  What I meant was that I
> think robustness is worth a small sacrifice of performance.
> 
> (And I have indeed spent many hours of gdb-time inside gc.c trying to
>  figure out what happened to my poor heap.  :)

So have I, which is why I definately don't want to subject any poor
users to it if it's avoidable ;) (it's hard enough when you know what
you're looking for and you know exactly how the gc works; what's worse
is that this looks exactly like a mistaken assignment problem, so you
can waste hours just going over your own code).  I really think this
is a case where the performance loss is worth it (though I don't think
this is the full five percent loss; it's really not doing enough to
screw us up that much, particularly since this should end up with the
cell in a register and cached, so that the subsequent inevitable
assignments are cheaper than they would've been; I am, of course, only
hypothesizing ;). Actually, there probably should also be a check in
the marking code for the allocated cells for a cellp in the cdr (the
allocated objects should show up pretty rarely, after all, and this
makes it safe to put cells in the cdr of newcells, although this is
not nearly as common as the malloc case).

Of course, if we wanted to be really picky about preformance, we could
just remove the increment of the cell count, which is more expensive
and less necessary (although this should be used to make the gc a bit
smarter about not collecting for mallocs really soon after a
collection for cells).

-- 
Gregh