texmacs-dev
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]