Re: [O] compilation issues of new export framework

[Nicolas Goaziou]

Achim Gratz <address@hidden> 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