Hello,
Achim Gratz 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 drawer) wi
Hi Lawrence and all,
Lawrence Mitchell 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
> org-element-headlin
Nicolas Goaziou writes:
> Actually this is a bit different. Parsing doesn't backtrack. Look at
> `org-element-parse-buffer' through elp to see that elements are parsed
> only once.
Sorry for the loose terminology.
> The problem comes from `org-element-at-point'. To be effective, it needs
> to mov
Hello,
Achim Gratz 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).
>
> I've tr
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 w
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
[Reintroducing org mailing list CC]
On 05/05/2013 20:21, Nicolas Goaziou wrote:
Carsten Dominik 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 point out specific ones where
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
> be
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
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
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"
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 wrote:
> I've been looking at export runtimes for large documents with the new
> expor
12 matches
Mail list logo
