[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.