Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 11:30 AM David Kastrup <address@hidden> wrote:
> >> >> On a 64bit application, this would be somewhat more tenable, but we'd
> >> >> need to override operator new for smobs.
> >> >>
> >> >> Or do we?  Maybe the heap is collected by default, and we need to switch
> >> >> that off?
> >> >>
> >> > What do you mean with "heap is collected"?
> >>
> >> "Collected" is probably the wrong expression.  Sweeped and marked.  The
> >> proposed behavior by Guile developers is not to bother with individual
> >> mark hooks and just let the whole heap be marked and sweeped.
> >>
> >
> > Did we ever try this and publish results?
>
> No.  Since much of LilyPond's data containing SCM values is stored in
> STL containers, it would require serious messing with allocators to get
> there.

Good point! And I'd agree with you, but if I look at the source code,
I can't find much STL structures that really do this. There is
Grob_array that would have to be revised, and there is a couple of
Drul_array<SCM> instances.

There are a bunch of others (eg. in Slur_engraver), that mark into STL
structures, but they retain pointers to events (which are kept alive
through the Music structures) and grobs (which are only unprotected
when they are put into the System).

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen