This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
perf(cli): load only requested sub-system modules and inline require ipfs and ipfs-api #1350
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an alternative to #1336 inlining all the requires in every file for the CLI. This is a great idea but I wanted to see if it could be done with minimal disruption as well as other reasons.
I had a look at the good work in #1336 and have taken the best bits that provide us with the biggest gains 🚀
I've changed
src/cli/bin.js
so thatcommandDir
now takes aninclude
filter. The idea being to only include the command files for the sub-system the user asked for. i.e. if the user typesjsipfs files add
then we only requiresrc/cli/commands/files.js
.I've applied the changes @victorbjelkholm made to
test/cli/daemon.js
verbatim as this was also really beneficial.Inlining the
require
for js-ipfs and js-ipfs-api is totally worth it as these two have many many dependencies. I've added a comment next to each to make it obvious why it has been done.As a baseline,
npm run test:node:cli
took 12m57.607s.With the work in this PR, it took 6m26.499s.
I also ran #1336 and it took 5m52.966s.
So around ~30s slower than in #1336. It was never going to be faster, but it is a significantly smaller changeset, still reduces the test time for the CLI by over 50%, and addresses the concerns I raised here.