Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

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

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.

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