emacs-devel
[Top][All Lists]
Advanced

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

Re: Reworking loaddefs.el generation


From: Eli Zaretskii
Subject: Re: Reworking loaddefs.el generation
Date: Wed, 01 Jun 2022 14:07:22 +0300

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Alan Mackenzie <acm@muc.de>,  emacs-devel@gnu.org
> Date: Wed, 01 Jun 2022 07:13:37 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > The generation of `org.texi` from `org.org` is excruciatingly
> > slow, indeed.  Maybe we can better hide that latency with a more careful
> > scheduling, but maybe we could also try to speed it up: I mean if you
> > compare it to the time it takes for texi2pdf to process the result it's
> > rather shameful (after all, the generation of the `org.texi` seems
> > algorithmically a lot simpler).
> 
> If somebody want to poke at this, then perhaps this is a good starting
> point:
> 
> (progn
>   (require 'ox-texinfo)
>   (with-temp-buffer
>     (insert-file-contents "~/src/emacs/trunk/doc/misc/org.org")
>     (setq default-directory (expand-file-name "~/src/emacs/trunk/doc/misc/"))
>     (profiler-start 'cpu)
>     (org-export-to-file 'texinfo "/tmp/org.texi"))
>   (profiler-stop)
>   (profiler-report))
> 
> 
>         1564  19%                               - 
> org-export-resolve-fuzzy-link
> 
> looks pretty suspicious, for instance.  (And that thing should have an
> easier calling convention...)

Instead of trying to speed up this conversion, we could divide org.org
into 10 files, and prepare a Texinfo template that has the preamble
and a series of 10 @include's, one each for every partial file.  Then
most builds would take 1/10th of the time we see now, since situations
where more than one part will be modified are probably extremely rare.



reply via email to

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