Re: Almost, but not quite: C++ STL in LilyPond

[Han-Wen Nienhuys]

On Wed, May 6, 2020 at 11:42 AM David Kastrup <address@hidden> wrote:
> > Or, we could globally map new/delete to GC_malloc and GC_free.
>
> That would vastly increase the amount of GC-scanned memory, and GC
> scanning is already slow.

I'd first measure this carefully before spending time on a complex
rewrite. The last time I tried, I hadn't fixed the heap scaling, so we
have no current data on this. I'd wager that most of the memory we
allocate (especially structures that are persistent) are under GUILE
GC control anyways, so it shouldn't make much difference. (Maybe you'd
have to redo Grob_array, though).

> > The GUILE folks may not love finalizers, but is there any evidence
> > that they're really going to get rid of them? Other foreign function
> > integrations willl need them too, because they need them to manage
> > non-memory resources (eg. files).
>
> Sure, but we require them for everything right now and that does not
> match normal use.  We could reduce this to require them for everything
> that does not use STL.  Which brings us back to the original problem.

Can you sketch the problem you want to address with a code example? I
still don't understand your specific proposal.

> At any rate, the principal request here was to consider other options
> before using previously unused STL structures as part of Smobs because I
> see options that might benefit from them.  Whether to use those options
> will be dependent on actual code I put out to preview.  I just don't see
> the point in making it harder to get to that point when it can easily be
> avoided.

I wish we would first look at getting rid of our GUILE 1.8 support.
Once we move to Boehm GC exclusively, we can simpilfy our code by a
lot, and it will be easier to experiment with different approaches to
address remaining problems.

In my mind, supporting GUILE 2.x means supporting byte compilation
because we'd otherwise regress startup speed by a second or so.

That is currently blocked on your proposed alternative to
https://codereview.appspot.com/577720043/ . Or did I miss an update on
that topic?

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