@michal oh, nice! I try to keep an eye on compiler performance as well, and I thought of keeping a graph but never got around to do it, thank you so much!
I think the jump up was when we started to run the type checker in gen. Adding more checks and features always adds more overhead, but I also try to speed things up whenever I can.
@michal Another complicating factor is that the compiler itself is growing. So over time the amount of work is also increasing. So this is tracking three things at once:
- how fast the compiler runs
- since the compiler is written in Teal, how fast is the generated code*
- the bigger tl.tl is, the longer it takes to compile it
@michal * this second point shouldn't matter much since the output is virtually 1-to-1 with Lua, but yesterday I was playing with some "optimizations" (e.g. a mode to remove assert() calls, or replacing them with if statements, etc) but then adding the "optimizer" meant both a bigger compiler (more stuff to compile) and longer compile times (the additional pass). to compare if the output was faster, I had to compile not itself, but the older version
@michal and then I ran the "optimized" build with the optimizer itself disabled so it would do a similar amount of work.
Unfortunately the difference between the original and "optimized" versions were within statistical noise, so I decided to shelve the experiment for now.
@michal The most effective way to speed up the compiler nowadays would be to add some on-disk caching to avoid recompiling all required files whenever a file is compiled.
But yeah, single-file compiler performance is a good metric to keep an eye on!
@michal On a related note, yesterday I cut the execution time of the test suite in half by disabling Busted's "auto insulation" feature (which would reset the Lua environment in between each test)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!