texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Disastrous boot time for new versions


From: Joris van der Hoeven
Subject: Re: [Texmacs-dev] Disastrous boot time for new versions
Date: Wed, 5 Mar 2003 12:14:29 +0100 (MET)

> I think we should not forget that GUILE is a language for _extension_.
> Not a language for application development. For example, it is fully
> interpreted. In that respect, I think that TeXmacs is actually
> _abusing_ GUILE.

This is a surprising statement, because you are the principal person
who urged me to rely more on Guile for the top-level interface.

> That is not a philosophical problem to me. But the more texmacs will
> use GUILE as a application language (instead of a mere extension
> language) the more it will make sense to use a more efficient
> implementation of Scheme.

Do you know of more efficient implementations,
which can also be used of extension languages?

Maybe you mean that we should compile part of the scheme programs.
Are scheme compilers good at dealing with macros?

> Disclaimer: I am not a system programmer.
> 
> One thing that can take up a lot of kernel and i/o time is loading
> many small files. For example, on my system (using ext3 on kernel
> 2.4.20), when compiling the user manual, I see that about half the CPU
> time is spent in the kernel. Maybe opening and closing many files may
> hit some bottlenecks in the filesystem implementation.
> 
> Also, reading many files may defeat read-buffering. Once TeXmacs has
> been loaded once (and assuming there is enough free RAM), the loaded
> files are cached. That does not prevent hitting filesystem
> bottlenecks, but that definitely prevent from waiting for drive seeks.
> 
> TeXmacs already has an caching system for style files. Maybe it would
> help to implement such a caching for scheme files, encoding files,
> etc.

Could be; it would be good to test whether a lot of time is indeed
spent on loading small files.





reply via email to

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