Hi, due to the reader-rewrite, I asked in the lilypond-list for testing, because they are likely the strongest power-user of the reader. Han-Wen Nienhuys checked performance in the benchmark suite: > $ cat ../bench.ly > #(define (microseconds) > (let* ((t (gettimeofday)) > (us (/ (cdr t) 1000000.0))) > (+ (car t) us))) > > #(define start (microseconds)) > > % \include "bench-largeexp.ly" > \include "bench-manysmall.ly" > > #(newline) > #(display (- (microseconds) start)) > > Parsing & evaluating '(1 2 3) 200 times. > - guile 1.8: 1.25ms > - guile 2.2: 3.2ms > - guile 3.0.6: 2.08ms > > Parsing & evaluating the giant expression in define-grobs.scm once: > > - guile 1.8: 10.6ms > - guile 2.2: 166ms > - guile 3.0.6: 71ms > > Parsing & evaluating the giant expression in define-grobs.scm once > (but quoted, ie. not real evaluation): > > - guile 1.8: 10.0ms > - guile 2.2: 13ms > - guile 3.0.6: 12.8ms > > In summary, the read speed itself for large expressions is on the same > order as 1.8, but for many small expressions (which is a much more > common use-case) there is still a 60% slowdown. >> asking here because I want to avoid surprising and avoidable changes >> that block Lilypond. I consider Lilypond to be the most important >> flagship project of Guile, and I want to do what I can to prevent >> unnecessary friction. > I appreciate the heads up you gave here today, but from our side, it > doesn't seem like the Guile project is much concerned with our needs. > The evaluation speed of GUILE 3.x is still pretty poor. Having fast, > JIT'ed code seems interesting in theory, but the way it's implemented > in Guile 3.x is a giant headache: the separate byte compilation is > extremely slow, and it is hard to manage (where should the .go files > be stored/installed, how/when are they generated etc.). It also > doesn't match our use case, because a lot of the code that we have > comes from .ly files, so it cannot be precompiled. Are there ways to improve this? For example sticking to the baseline compiler (as described in the wingolog: https://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile ) >> The article linked above shows that setting -O1 as optimization of the >> code could help (if you’re not already doing that). > The article gives a pointer to the code, which is > module/language/tree-il/compile-bytecode.scm. I ran > > for c in $(git log module/language/tree-il/compile-bytecode.scm|grep > commit|awk '{print $2;}'); do git show $c ; done | grep -i doc > > to look for documentation, but couldn't find it. The module has one > exported symbol, which is compile-bytecode. > > Could you give some practical tips on how we'd use this? Can someone help with this? It would be pretty cool if there were a simple way to speed-up lilypond like changing optimization level that just got lost in communication (or missing docs). Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken