Am Sonntag, dem 18.04.2021 um 10:35 +0000 schrieb Werner LEMBERG: > > > Working towards a fork of Guile 1.8 was never meant to be a good > > > option, rather as a last resort if speed differences make normal > > > work too painful. > > > > Well, the question of this thread was: What is "too painful"? Do we > > require less "speed differences" than what I measured? In general: > > What are the criteria to "switch"? > > For me, the speed of Guile 2.x without compiled Scheme bytecode would > be too painful.
Agreed for user installations, but we have a work-around there. So what about development? Do we *require* compiled bytecode to work there? Let me quote my initial message here: > In my opinion, the numbers show that we *must have* compiled bytecode > for user installations in order to reach acceptable performance > (memory usage seems to be fine). And while compilation by invoking > LilyPond is somewhat odd, it works and would be viable for the > beginning. > For development, I'm less convinced. Sure, 'make test' and 'make doc' > get faster but the compilation itself takes a considerable amount of > time. Moreover it is my understanding the Guile is notoriously bad at > determining which files to recompile, in particular when macros are > involved. > Personally, I would be ok with the moderate slowdown if that was the > only thing preventing a hypothetic switch to Guile 2.2, and the > arising question is really a matter of prioritizing: There are other > items that need solutions before that switch could happen (in > particular the release process for binary builds and documentation). > What do others think? Or would you say that proper bytecode > compilation is required before moving to Guile 2.2? (with no clear > estimate how feasible that is and how long it would take) Jonas P.S.: This is getting a bit annoying, but I honestly have no clue how I could ask the questions in a better way that you answer all of them in one reply...
signature.asc
Description: This is a digitally signed message part