[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Darcy's plan for GNU TeXmacs 2.1.1
From: |
TeXmacs |
Subject: |
Re: [Texmacs-dev] Darcy's plan for GNU TeXmacs 2.1.1 |
Date: |
Fri, 26 Nov 2021 09:40:35 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi Joy,
Thanks for the heads up. This is very interesting information.
In the worse case, we can stick with Guile 1.8...
Best wishes, --Joris
On Thu, Nov 25, 2021 at 03:41:21PM +0000, Joy Yang Qiping via Texmacs-dev wrote:
> Hi Joris,
>
> > About plans for Scheme. After the benchmarks, I got somewhat confused.
> >
> > If S7 were systematically faster than Guile (at least than Guile 1.8),
> > then I think that moving to S7 is the simplest option for us.
> > Otherwise, we should keep playing with Guile 3 too.
> >
> > If my understanding is correct, then the main problem is the LaTeX export.
> > Does anyone understand why this is so much slower with S7?
> >
> > Another decision we could make is that we wish to keep the support
> > for various versions of Scheme. But then we would need a branch that
> > works for both S7 and Guile 3.
>
>
> Moving to S7 may not be as simple as we would like. Here is another issue
> that troubles me. Over my own usage experience, TeXmacs under S7 could
> consume more memory than I would like (over 1GB for single document editing).
>
> I think S7 will benefit from a more sophisticated gc implementation. From
> what I have seen through the code, they are using the same memory pool for
> every scheme object, which isn’t ideal for TeXmacs. Since TeXmacs not only
> has a linear growth of persistent object, e.g., edit history for instance,
> during editing, but also has a lot of side computations that claims some
> memory for a short duration. This means the gc will often get triggered and
> are slower and TeXmacs will benefit from having several levels of memory
> pools (from persistent to short-lived) to adapt to different memory usage
> pattern. The memory pool grows exponentially. I have tried to tune its
> exponential parameter from 2 to 1.2~1.5. But from what I have observed, it
> only delays the inevitable. The current S7’s gc implementation cannot
> guarantee long-term stability of TeXmacs — memory consumption will grow to a
> very high level. I don’t think it is a good idea to go through with S7 as is.
> I could try to turn that into a linear growth, which should work fine for
> TeXmacs in most cases (I’m guessing). But it really isn’t meant to be a
> general purpose scheme implementation with those changes. We could also find
> ways to reduce those persistent memory throughout editing. I might also try
> to look for some parameters within TeXmacs that affect those (how many
> editing history to keep for instance) and see if it helps.
>
> I think it would be better to keep both S7 and Guile 3 working for now. Right
> now the main problem with Guile 3 is Windows support. Neither is the perfect
> solution for us :(
>
> Best regards,
> Joy
>
>
>
> _______________________________________________
> Texmacs-dev mailing list
> Texmacs-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/texmacs-dev