From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: Exporting large documents Date: Mon, 06 May 2013 20:41:54 +0200 Message-ID: <87vc6wuf0t.fsf@Rainer.invalid> References: <877gjnojsq.fsf@Rainer.invalid> <5654CA29-5F6D-4E8B-8B8B-C3609D76D189@gmail.com> <8761z5gw6w.fsf@gmx.li> <707EAAA5-D27C-47B7-9A1E-874C3A375BD9@gmail.com> <87zjwcwc4b.fsf@gmx.li> <877gjfgnl9.fsf@gmail.com> <0F877AB5-D488-4223-B0E7-F11B4B973614@gmail.com> <87ip2xfd0x.fsf@gmail.com> <51878F09.1050904@ed.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:38065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZQMX-00015B-IK for emacs-orgmode@gnu.org; Mon, 06 May 2013 14:42:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZQMT-0005WY-ET for emacs-orgmode@gnu.org; Mon, 06 May 2013 14:42:13 -0400 Received: from plane.gmane.org ([80.91.229.3]:59117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZQMT-0005WF-7c for emacs-orgmode@gnu.org; Mon, 06 May 2013 14:42:09 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UZQMP-0000Ty-30 for emacs-orgmode@gnu.org; Mon, 06 May 2013 20:42:05 +0200 Received: from pd9eb09f9.dip0.t-ipconnect.de ([217.235.9.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 May 2013 20:42:05 +0200 Received: from Stromeko by pd9eb09f9.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 May 2013 20:42:05 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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 250000 times giving ~ 80 seconds total time (out of ~200 > total). I've traced this a bit and the question does warrant further investigation. Exporting the introduction without any duplications already shows some interesting things: the property drawer for the introduction is scanned a whopping 137 times, followed by 134 times the cindex entry following it, followed by 125 times the "Summary" headline. The header options feature prominently with around 100 scans each as well. The rest of the calls have mostly just a single invocation, but there are some instances where parts of the tree are traversed multiple times in succession to apparently adjust the :end property to the leaf element in small increments or decrements. If elements are mutable during parsing then caching is more difficult as well, obviously. > So it sort of feels like actually what is needed is microoptimisations > of the bits of the export engine that are called the most. Looking at the traces I'd think if we could eliminate the repeated backtracking to adjust the leafs or at least skip over those elements in a backtrack that are already fully parsed instead of parsing them again, that would be a good start. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves