Some of you might have noticed, that lately I've been hacking hard on #ecl generic function tabled-based dispatch. I've composed a roadmap document for further work with concrete optimizations proposals that I'm executing now:
https://www.patreon.com/jackdaniel_kochmanski/posts/optimizing-ecl-161129531
as you might have noticed, the link is to patreon. I'd greatly appreciate support!
If you have some interesting remarks about this proposal, then please share!
ecl-26.5.5 is a baseline (current dispatch)
ecl-arwen is a version with removed numerous memory indirections and elided without-interrupts to cache miss
ecl-pre-fastgf is a version with per-gf cache and quick lookup for the last element (in the document I'm saying that I've rejected the idea of per-gf cache, but in all honesty it is still on the table :)
Q: Will I notice a difference if I mostly use "normal" functions (as in (defun f (x) ...))?
Q: What is the performance impact on McCLIM?
Thank you for you help.
If you use libraries that use generic functions, or interfaces that do, then you may notice a difference. For example
(defclass foo ((a :reader foo-a)))
the FOO-A will benefit from it. Other functions are GRAY stream operators, PRINT-OBJECT, MAKE-INSTANCE etc etc. That said if your program bottlenecks are in heavily optimized code that does not invoke generic functions, then you shouldn't notice the difference.
In fact, for most programs speeding up the generic function dispatch won't make a big difference, it matters only when we are trying to heavily optimize things -- but this observation is universally applicable to compilers (and runtimes) that run at a decent speed from get go.
That said, I've gained some insight to how hash tables work, so after I'm done with dispatch improvements, I plan to refactor hash tables -- and that should benefit even code that doesn't bother with CLOS.
As of McCLIM performance impact - I expect that it will speed up McCLIM by a noticeable margin, because it heavily relies on generic functions.
Related question:
Which version of ECL should I install, if I wanted to try out McCLIM from quicklisp?
I had to include /usr/pkg/lib in LD_LIBRARY_PATH to keep configure happy.
Took me a while to realise that.
But now ecl_min is happily compiling files.
@alexshendi ecl_min is for building ecl itself - it is incomplete. to build ecl from source do
./configure --prefix=/path/ && make && make install && make check
Thank you. In fact I did just that. I have just said the above to indicate that the build was progressing.
On my way home now. When I left, ECL had just compiled something called "DREI" and was busy with "BABEL-CHARSET" or so.
Wonder if it will be finished...
@alexshendi ecl has very slow compilation time -- after compiling performance us much more acceptable.
btw, drei is not a direct dependency of mcclim since the last mcclim release.
According to quicklisp mcclim version is:
mcclim-2026-01-01-git
That doesn't work:
(ql:quickload "mcclim") ;; works
(ql:quickload " clim-examples") ;; errors
;; Complaint is: DRAW-MATRIX not a function [1]
Test suite outputs warning:
Signals delivery fails constantly [2]
[1] output of the above load process
https://alexshendi.sdf.org/ecl.log.txt
[2] output of "gmake check"
https://alexshendi.sdf.org/tests.log.txt
Can confirm it works with "master" branch from https://codeberg.org/mcclim/McCLIM.git.
However execution speed is disappointing [tried (clim-demos::demodemo)].
@alexshendi McCLIM heavily relies on generic functions, and ECL is known for doing a poor job with dispatching them (that's why I work on that right now!).
If you are interested in the current progress:
https://turtleware.eu/static/paste/beaf6fac-current-results.org
this doesn't include experimental results with PIC cache (because it skews yields from the current optimizations greatly, I've postponed it for later).
Daniel Kochmański
Alexander Shendi
