Re: [O] compilation issues of new export framework
Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou n.goaziou at gmail.com writes: On the other hand, `org-element-type' and al. from org.el are called less often. So, it is not a problem if they are compiled as function calls. They are normally not compiled as function calls, only in single mode. Regarding commit 6b7101b91, did you intend to demote org-element-nested-p to a defun or was this just a leftover from the earlier experiment? I found that inlining it was an overkill. So the change is intentional. Regards, -- Nicolas Goaziou
Re: [O] compilation issues of new export framework
Nicolas Goaziou writes: I found that inlining it was an overkill. So the change is intentional. Thanks for the confirmation. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] compilation issues of new export framework
Nicolas Goaziou writes: Yes, I noticed this one too, but I don't know yet from where it could come from. It comes from the two autoloads, or probably only the second one as the first is later declare-function'ed anyway. If you declare these, then the defsubst get sometimes compiled as function calls and sometimes as inlined functions (the normal mode of compilation inlines them). --8---cut here---start-8--- diff --git a/lisp/org.el b/lisp/org.el index 2bfca4e..c679c5d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -137,9 +137,6 @@ (defvar org-heading-regexp ^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$ (declare-function org-table-maybe-eval-formula org-table ()) (declare-function org-table-maybe-recalculate-line org-table ()) -(autoload 'org-element-at-point org-element) -(autoload 'org-element-type org-element) - (declare-function org-element--parse-objects org-element (beg end acc restriction)) (declare-function org-element-at-point org-element (optional keep-trail)) @@ -152,6 +149,7 @@ (defvar org-heading-regexp ^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$ (declare-function org-element-nested-p org-element (elem-a elem-b)) (declare-function org-element-parse-buffer org-element (optional granularity visible-only)) +(declare-function org-element-type org-element (element)) (declare-function org-element-property org-element (property element)) (declare-function org-element-put-property org-element (element property value)) --8---cut here---end---8--- If instead you really want them always replaced with the definition of the defsubst (on the assumption that this is indeed faster than a function call or permits better optimization by the bytecompiler), then these would need to be moved to org.el and their declarations removed. Alternatively the defsubsts could go into a separate file that is then required from both org.el and org-element.el None of these options solve the larger problem of the circular dependencies. PS: If compiled single, four Babel tests fail; three of them with an (invalid-function org-export-with-buffer-copy). The function it complains about is actually a macro in ox.el that is used in org-export-as before its definition. Not cool, it must be moved before org-export-as. The tests then pass with a single-compiled version of org. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] compilation issues of new export framework
Achim Gratz strom...@nexgo.de writes: It comes from the two autoloads, or probably only the second one as the first is later declare-function'ed anyway. If you declare these, then the defsubst get sometimes compiled as function calls and sometimes as inlined functions (the normal mode of compilation inlines them). Strange, these autoloads were already there before the merge. If instead you really want them always replaced with the definition of the defsubst (on the assumption that this is indeed faster than a function call or permits better optimization by the bytecompiler), then these would need to be moved to org.el and their declarations removed. Speed is the whole point, indeed. A quick profiling with and without defsubst gives me: | defsubst | org-element-parse-buffer | 10 | 16.252699 |1.6252699 | | defun| org-element-parse-buffer | 10 | 19.812426 | 1.9812425999 | It is about 20 % faster. Alternatively the defsubsts could go into a separate file that is then required from both org.el and org-element.el None of these options solve the larger problem of the circular dependencies. Moving `org-element-type' and al. into org.el would be out of context. We may be able to require org-element from the beginning of org.el, but I think there's some serious work involved. PS: If compiled single, four Babel tests fail; three of them with an (invalid-function org-export-with-buffer-copy). The function it complains about is actually a macro in ox.el that is used in org-export-as before its definition. Not cool, it must be moved before org-export-as. The tests then pass with a single-compiled version of org. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] compilation issues of new export framework
Completing myself, Nicolas Goaziou n.goaz...@gmail.com writes: Speed is the whole point, indeed. A quick profiling with and without defsubst gives me: | defsubst | org-element-parse-buffer | 10 | 16.252699 |1.6252699 | | defun| org-element-parse-buffer | 10 | 19.812426 | 1.9812425999 | It is about 20 % faster. On the other hand, `org-element-type' and al. from org.el are called less often. So, it is not a problem if they are compiled as function calls. Eventually, I'd say that the situation is fine as it is. Regards, -- Nicolas Goaziou
Re: [O] compilation issues of new export framework
Hi Nicolas,
an oddity occurs since the new exporter moved into core (I don't think I
had seen this before, so maybe you can relate to what is different now):
--8---cut here---start-8---
Compiling /lisp/org-mode/lisp/org.el...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
--8---cut here---end---8---
This only happens when using byte-recompile-directory, which means
org-element has already been loaded in that session and is present as a
byte-compiled file. I haven't yet found where in org.el these loads are
triggered, but it seems that this might be related to macro expansion.
In any case, the resulting org.elc file therefore depends on the
compilation method, which is highly undesirable. I haven't been able to
analyse this further.
Another sticky point is your use of declare-function: some of these are
actually defsubst, not defun:
org-element-{contents,nested-p,element-property,put-property}
I don't think they will be inlined unless their definition has been
interned, declaration alone will not suffice. I don't see an easy way
to factor out those parts from org-element that are needed by org, but I
suggest that we should find one.
There are more errors when doing a make ORGCM=slint2 compile in the
last pass. These files are probably all just missing an
(eval-when-compile (require 'cl))
but I only checked ox-md.
--8---cut here---start-8---
Compiling single /lisp/org-mode/lisp/ox-beamer.el...
In end of data:
ox-beamer.el:1250:1:Warning: the following functions are not known to be
defined: case, action, defaction, option, otherwise, headline, target
Wrote /lisp/org-mode/lisp/ox-beamer.elc
Compiling single /lisp/org-mode/lisp/ox-icalendar.el...
In org-icalendar-entry:
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
In end of data:
ox-icalendar.el:974:1:Warning: the following functions are not known to be
defined: case, category, todo-state, local-tags, all-tags, incf, all,
unblocked, hour, day, week, month, year
Wrote /lisp/org-mode/lisp/ox-icalendar.elc
Compiling single /lisp/org-mode/lisp/ox-jsinfo.el...
In end of data:
ox-jsinfo.el:261:1:Warning: the following functions are not known to be
defined: case, path, sdepth, tdepth, otherwise
Compiling single /lisp/org-mode/lisp/ox-md.el...
In end of data:
ox-md.el:494:1:Warning: the following functions are not known to be defined:
case, on, trans, off
--8---cut here---end---8---
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
Re: [O] compilation issues of new export framework
Hello,
Achim Gratz strom...@nexgo.de writes:
an oddity occurs since the new exporter moved into core (I don't think I
had seen this before, so maybe you can relate to what is different now):
Compiling /lisp/org-mode/lisp/org.el...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Yes, I noticed this one too, but I don't know yet from where it could
come from.
This only happens when using byte-recompile-directory, which means
org-element has already been loaded in that session and is present as a
byte-compiled file. I haven't yet found where in org.el these loads are
triggered, but it seems that this might be related to macro expansion.
In any case, the resulting org.elc file therefore depends on the
compilation method, which is highly undesirable. I haven't been able to
analyse this further.
Another sticky point is your use of declare-function: some of these are
actually defsubst, not defun:
org-element-{contents,nested-p,element-property,put-property}
I don't think they will be inlined unless their definition has been
interned, declaration alone will not suffice.
I don't know either how inline functions behave in this situation.
I don't see an easy way to factor out those parts from org-element
that are needed by org, but I suggest that we should find one.
It is always possible to make them regular functions. Some profiling may
be necessary, though.
There are more errors when doing a make ORGCM=slint2 compile in the
last pass. These files are probably all just missing an
(eval-when-compile (require 'cl))
but I only checked ox-md.
Indeed. Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] compilation issues of new export framework
Nicolas Goaziou writes: Yes, I noticed this one too, but I don't know yet from where it could come from. Hmm. If you don't know, then this is even more worrysome. Can't spend more time on this now, unfortunately. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
