Hi Lawrence and all,
Lawrence Mitchell we...@gmx.li writes:
org-up-heading-safe263822 84.507423221 0.0003203198
org-element--parse-elements311340.774293673 0.0130980705
org-back-to-heading1209279 40.394825581 3.340...e-05
Hello,
Achim Gratz strom...@nexgo.de writes:
Nicolas Goaziou writes:
The problem comes from `org-element-at-point'. To be effective, it needs
to move back to the current headline, and start parsing buffer again
from there. That means the first element after the headline (often
a property
[Reintroducing org mailing list CC]
On 05/05/2013 20:21, Nicolas Goaziou wrote:
Carsten Dominik carsten.domi...@gmail.com writes:
I don't think there's much to do about that. Though, some tools could
benefit from caching, like Lawrence did for
`org-export-resolve-fuzzy-link'.
Could you
Lawrence Mitchell wrote:
[...]
And here's the profile for exporting the whole of orgmanual.org
to latex. You can see that a lot of the time comes from quite
cheap functions that are called lots.
org-latex-export-as-latex 1 415.52740777 415.52740777
org-export-to-buffer
Lawrence Mitchell writes:
org-element--current-element takes (on my machine) 0.0003 seconds per
call. However, when exporting 128x the orgmanual introduction, it's
called around 25 times giving ~ 80 seconds total time (out of ~200
total).
I've traced this a bit and the question does
Hello,
Achim Gratz strom...@nexgo.de writes:
Lawrence Mitchell writes:
org-element--current-element takes (on my machine) 0.0003 seconds per
call. However, when exporting 128x the orgmanual introduction, it's
called around 25 times giving ~ 80 seconds total time (out of ~200
total).
Hi Lawrence,
thanks for doing this. Stuff to think about - but no good
ideas for improvements here either - I am just not familiar enough
with the export engine. Nicolas, it would be interesting to
hear from you if you have comments and ideas about quadratic
behavior of the exporter, and if you
Carsten Dominik wrote:
Hi Lawrence,
thanks for doing this. Stuff to think about - but no good
ideas for improvements here either - I am just not familiar enough
with the export engine. Nicolas, it would be interesting to
hear from you if you have comments and ideas about quadratic
Carsten Dominik wrote:
Hi Achim,
this is an interesting experiment, thank you!
I think it would also be interesting to use elp to see which
function are taking up the non-linear time.
I did a bit of digging and here are the results. No potential
fixes though.
Taking the Introduction
Lawrence Mitchell writes:
I did a bit of digging and here are the results. No potential
fixes though.
Thanks for beating me to it, that frees up quite some processor cycles
on my end! :-)
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Waldorf MIDI
I've been looking at export runtimes for large documents with the new
exporter. The example I've used is the orgmanual.org from Tom. I first
exported each subtree standalone, then the document as a whole to
texinfo. The startup of Emacs takes about 1 s of user time and 1.5 s of
wall time, these
Hi Achim,
this is an interesting experiment, thank you!
I think it would also be interesting to use elp to see which
function are taking up the non-linear time.
- Carsten
On 27.4.2013, at 21:28, Achim Gratz strom...@nexgo.de wrote:
I've been looking at export runtimes for large documents
12 matches
Mail list logo
