A few notes -
The last time I did any serious profiling of the sclang VM, the biggest costs were not necessarily in places that would obviously be improved by LLVM or doing JIT tracing type things. If SC performance is an issue, it would be interesting to know WHERE/WHY it's an issue, and then look at targeted optimization of those specific cases. I think SC as a whole would get much more by simply (1) teaching folks some basics of profiling tools, (2) compiling a big, sorted, and voted-on list of bad-performance cases, and (3) slowly and boringly working down the list. The magic bullet solution is tempting but, for example, the only real sclang performance problem I've had in recent projects was related to 32 channels of uber-high resolution MIDI.
My 2¢ on sc4, in priority order:
- real debugger (this is doable currently, maybe two person-weeks of work on the VM, and a similar amount of work on the IDE to support)
- build SOLID interprocess communication between server/lang/ide (chrome runs every tab and plugin in a separate process, and it's completely transparent and performant)
- Server introspection (I should be able to programmatically query ins/outs of all ugens in a synth, view detailed CPU usage, etc. 90% of my (and probably everyones) sc problems are related to synths not doing expected things / blowing up / using too much cpu. Let's make those problems go away.
- Taking the CV class (and maybe the most recent Responder refactoring) as a basis, and build a robust general signals solution for connecting UI, synths, buses, data. Connecting UI/controls to synths easily and elegantly is one of the hardest and most annoying things for new users I think, and doesn't really get much more elegant if you know what you're doing.
- Proper npm-style package manager. Ach. (Been working on this for ages)