Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Fri, Jan 24, 2020 at 12:45 PM David Kastrup <address@hidden> wrote:
>> >> 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.
>
> We should be able to short circuit all of this by doing
>
> +#if GUILEV2
> +
> +void *
> +operator new(std::size_t size) {
> +  return scm_gc_malloc(size, "c++ new");
> +}
> +
> +void
> +operator delete(void *p) {
> +  return scm_gc_free(p, 0, "new");
> +}
> +
> +#endif

I wouldn't do that since it would affect all allocated memory even
outside of LilyPond proper, like for STL bookkeeping and file buffers
and whatnot.

> unfortunately, it crashes somewhere near the start of GUILE initialization.
>
> (in GUILE2 the above functions directly call GC_MALLOC, GC_FREE, so I
> don't understand why this would be a problem.)
>
> I am actually quite attracted to moving to GUILE 2 and using BGC.
> Debugging GC problems (eg. a constructor triggering GC, which then
> deletes the smob under construction) were one of most hairy things to
> get right.

Them not being done right is the reason for the existence of the
Pre_init class...

-- 
David Kastrup