Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> 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 few other structures I think.  Basically one would need to
go through all mark_smob routines and check for loops over arrays or
other indirections.  You are right that their number seems reasonably
small.

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

Stream events are not kept alive through music structures.  There is a
reverse mechanism that I think should actually get removed:

  /*
    ES TODO: This is a temporary fix. Stream_events should not be
    aware of music.
  */
  e->set_property ("music-cause", self_scm ());

(it's in lily/music.cc).

At any rate, stream events tend to be kept alive by engravers which in
turn are kept alive by their contexts.  Events are also kept alive as
"cause" of grobs.

> and grobs (which are only unprotected when they are put into the
> System).

-- 
David Kastrup