Re: Permanently fix org versioning breakage during builds?

["João Távora" <joaotavora@gmail.com>]

On Mon, Dec 25, 2023, 13:55 Ihor Radchenko <yantar92@posteo.net> wrote:

> I doubt that you are right about 99.9%, because I know that we have some
> macros (like `org-with-wide-buffer') that are utilized in
> performance-critical code - org-element-cache.

You want to bet on it? You really do believe the cost of an indirect funcall
outweighs multiple buffer allocations, plust whatever &rest body does?

(require 'cl-lib)

(defmacro joaot/progn (&rest body)
  `(progn ,@body))

(defmacro joaot/funcall (&rest body)
  `(joaot/with-funcall (lambda () ,@body)))

(defun joaot/with-funcall (fn) (funcall fn))
(when nil

(benchmark-run-compiled 100000 (joaot/progn (cons nil nil)))
;;(0.03082571 2 0.026723563000004447)
;;(0.030770479000000003 2 0.02662909699999716)
;;(0.030249778 2 0.02616808300000173)
;;(0.025063519000000003 2 0.021807326999997656)
;;(0.022791136 2 0.020065053000003275)

(benchmark-run-compiled 100000 (joaot/funcall (cons nil nil)))
;;(0.028634259999999998 2 0.02006373300000064)
;;(0.028718769 2 0.020229722999999922)
;;(0.02806812 2 0.020030715000004307)
;;(0.025772916 2 0.017697210000001462)
;;(0.026947274 2 0.018522359999998628)

(benchmark-run-compiled 100000 (joaot/progn (with-temp-buffer)))
;;(1.4586596770000002 179 1.2495902690000023)
;;(1.434278908 179 1.228926580999996)
;;(1.444412169 179 1.2385162100000002)
;;(1.445273846 179 1.2392989229999998)
;;(1.464507893 179 1.2581699959999995)

(benchmark-run-compiled 100000 (joaot/funcall (with-temp-buffer)))
;;(1.4344190810000002 179 1.223486917999999)
;;(1.418460156 179 1.211255973)
;;(1.449469906 179 1.232802902000003)
;;(1.419341703 179 1.2082177509999994)
;;(1.517436337 179 1.2952383430000012)

The time is completely dominated by allocation and
garbage collection.

A single cons allocation per macroexpansion is enough
to make the difference unmeasurable.  In fact, to be able
to measure it, you'll have to make body completely empty
and run it tens of milions of iterations to be able to measure
anything perceivable in the tenths of a second.

> And it is not the only concern why I do not feel that your suggestion is
> a good idea:
>
> - The problem with stale macros is not just Org mode's problem - it is
>   the problem with Elisp compiler machinery. A very hard one that is
>   non-trivial to solve.

It doesn't have a solution! It's just what macros give you: syntax
manipulation in exchange for late binding. You must add functions
back to regain Lisp's late binding and deal with Lisp's build systems
which don't usually let you specify dependencies between files.

> - The rest of Emacs just leaves the problem with macros as is and the
>   only reason why Org mode touched it is that it was simply a side
>   effect of how org-assert-version is implemented - it is first and
>   foremost aiming at handling the issue with multiple Org mode versions
>   being loaded at the same time, while the side effect of detecting
>   stale macros was a bonus.
>
> - Even if I solve the problem with macros using the technique you
>   proposed, the problem with mixed versions still has to be handled.

I've already explained that is a different other for people who use ELPA
& git to track bleeding edge.  It has another solution.  It's very confusing
to see you reject a solution to a given real problem just because it
doesn't solve another completely different one.

> - Further, fixing the stale macro problem means rewriting all the
>   existing, and, more importantly, future Org mode macros - an extra
>   maintenance burden which I am very hesitant to take.

So you'd rather bother everyone else with broken builds...
And what maintenance burden.  It's much easier to write macros
like this.  No hygiene concerns, no awkward ',foo' everywhere.

> - And that maintenance burden also comes with an additional downside of
>   potential performance degradation.

This bullet is a repeat / filler. Fallacious argument with no data.  I've given
you hard data. Read it.

> So, all-in-all, I do not see the idea with wrapped macros as something
> practical for Org mode.

I tried my best. Repeatedly in this argument you have made erroneous
statements and logically fallacies. And when I correct them, you just came
back whit some more. I have handed you a solution on a plate to fix a real
problem, and you drag your feet so it can stay "your solution".
Can't beat hubris.  Good luck.

João