I have v2020.12 of Rakudo installed on my computer and have also built v2020.12 from source. When profiling startup times, I noticed the following results: (these benchmarks use hyperfine, but I also got similar results with time).
$ which raku
/opt/rakudo-pkg/bin/raku
$ /opt/rakudo-pkg/bin/raku --version
Welcome to Rakudo(tm) v2020.12.
Implementing the Raku(tm) programming language v6.d.
Built on MoarVM version 2020.12.
$ /opt/rakudo-pkg/bin/raku ~/.raku/bin/red --help > /dev/null # make sure modules are compiled
$ hyperfine -i '/opt/rakudo-pkg/bin/raku /home/dsock/.raku/bin/red'
Benchmark #1: /opt/rakudo-pkg/bin/raku /home/dsock/.raku/bin/red
Time (mean ± σ): 890.0 ms ± 15.5 ms [User: 1.411 s, System: 0.068 s]
Range (min … max): 861.3 ms … 913.4 ms 10 runs
Warning: Ignoring non-zero exit code.
$ ~/forks/rakudo-clean/install/bin/raku --version
Welcome to Rakudo(tm) v2020.12.
Implementing the Raku(tm) programming language v6.d.
Built on MoarVM version 2020.12.
$ ~/forks/rakudo-clean/install/bin/raku ~/.raku/bin/red --help > /dev/null # compile modules
$ hyperfine -i '~/forks/rakudo-clean/install/bin/raku /home/dsock/.raku/bin/red'
Benchmark #1: ~/forks/rakudo-clean/install/bin/raku /home/dsock/.raku/bin/red
Time (mean ± σ): 343.9 ms ± 7.9 ms [User: 461.3 ms, System: 43.9 ms]
Range (min … max): 328.1 ms … 355.9 ms 10 runs
Warning: Ignoring non-zero exit code.
As you can see, red --help took ~3× as long to execute when I used the version of raku installed in /opt. This isn't an issue specific to red – I also tested with zef --help and observed a similar issue. Interestingly, the issue did not occur if I ran the /opt copy of raku from inside the ~/forks/rakudo-clean/ directory.
This last point leads me to wonder whether the underling issue is somehow related to $PATH searches or something similar. (Maybe something like the difficulty Ruby has with $LOAD_PATH?)
A few alternatives:
- I have somehow misconfigured my raku install in a way that causes this slowdown, but people who installed raku correctly don't run into this issue (this possibility is why this is a question on SO rather than being reported as a bug).
- The default installation for raku causes this issue. Everyone experiences it, but we can fix it by updating build/install instructions.
- This is a bug in Rakudo that needs to be fixed at that level rather than through installation configuration.
- Something else/I'm more deeply confused.
I appreciate any help you can provide, including just letting me know if you also see the same large difference in start times. Thanks!
EDIT:
I did a bit more digging,and discovered the RAKUDO_MODULE_DEBUG environmental variable. After setting that, I discovered some more info – specifically, in the slower version (/opt/rakudo-pkg/bin/raku), I have a number of lines like the following:
1 RMD: Trying to load 77AFF4B677E65751FF5E96B6D6FA230222D29DFE.repo-id from /home/dsock/lib/.precomp
1 RMD: Repo changed:
9255FA5B5841CF5E09BDD37B3C43740099B4851F
97741FE305502F0915F57D977BCFC518F958D4FC
Need to re-check dependencies.
In contrast, loading the same dependecy with ~/forks/rakudo-clean/install/bin/raku produced the following output (among much else, of course).
1 RMD: Trying to load 77AFF4B677E65751FF5E96B6D6FA230222D29DFE.repo-id from /home/dsock/lib/.precomp
1 RMD: dependency: FFEE376ADAD76513435BB73B169C73EC50B35567 home#sources/FFEE376ADAD76513435BB73B169C73EC50B35567 CAB0E9BB22A61F32FA98CFEA40EDFDD6E4495D06 CompUnit::DependencySpecification.new(:short-name<CX::Red::Bool>)
This partly answers my question: the /opt version launches more slowly because it is re-checking dependencies. But this really just raises more questions. Why is that version finding something different when it looks in the same folder? Given that it is, why isn't it updating the cache properly so that it finds what it's looking for the next time it runs?
