This is a proof of concept to show that we don't need the macro run here at all. Whether this macro is indeed faster than the existing src/ecr/process.cr for all use cases is up for investigation, but these are the results of doing make clean clean_cache && time make && rm .build/crystal && time make, rebuilding the compiler with a cold and hot cache respectively, with this PR:
real 0m17.873s
user 0m31.251s
sys 0m2.823s
real 0m14.343s
user 0m14.761s
sys 0m1.097s
and without this PR:
real 0m22.057s
user 0m34.573s
sys 0m3.136s
real 0m15.532s
user 0m16.533s
sys 0m1.388s
I couldn't notice any significant differences when running the files under scripts/ that also use ECR.
This PR consumes about 120 MB more memory in the compiler itself, but note that there are no more subprocesses doing macro runs. It seems string.chars and those looper elements each contribute roughly 10 MB of memory.
This is a proof of concept to show that we don't need the macro
runhere at all. Whether this macro is indeed faster than the existingsrc/ecr/process.crfor all use cases is up for investigation, but these are the results of doingmake clean clean_cache && time make && rm .build/crystal && time make, rebuilding the compiler with a cold and hot cache respectively, with this PR:and without this PR:
I couldn't notice any significant differences when running the files under
scripts/that also use ECR.The
looper*variables are a workaround for not havingwhilein the macro language.This PR consumes about 120 MB more memory in the compiler itself, but note that there are no more subprocesses doing macro
runs. It seemsstring.charsand those looper elements each contribute roughly 10 MB of memory.