Re: commit 44ec60d to speed up MAPPLY1 via lambda optimization

Yes, %coerce-float-fun is a different beast. It actually doesn't need any
compilation at all, since basically it just calls the evaluator. Not much
to be gained from compiling that call, it's a waste of resources. Fix is in
the pipeline ...

Michel Talon <[email protected]> schrieb am So., 16. Aug. 2026, 13:11:

>
> Le 15/08/2026 à 19:45, Robert Dodier a écrit :
>
> Hey, I just saw commit 44ec60d which avoids calling COERCE on Lisp
> lambda expressions, which makes a lot of stuff faster, and makes
> pattern-matching stuff (e.g. ezunits) much, much faster. That is
> really terrific!
>
> It has always bothered me that pattern-matching stuff is (or was, I
> guess) much slower than built-in simplification, to the extent that it
> makes me think twice about bringing pattern matching into the picture
> for the purely practical reason that it slows down everything
> noticeably, so this optimization is going to be really helpful.
>
> We have seen in the past a similar explosion of compilation time (with
> sbcl which compiles all functions automatically) when using repeatedly
> coerce-float-fun (precisely there is a big coerce in %coerce-float-fun)
> from plot.lisp. This is used of course for plotting but also in other
> numerical stuff in the share directory (hompack, lbfgs, minpack, romberg,
> cobyla, colnew, etc.). It would be nice to ensure that the same thing you
> have done for mapply (keeping a copy of the compilation result in a hash
> table to avoid recompilation) covers all uses of convert with meval, so
> that all use case are speedied the same way.
>
>
> --
>
> Michel Talon
>
> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss