test: investigate slow request handler imports #6481
Draft
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.
Related to #6211
In 92ceb85, I set up a test which measures the import times of request handlers. It is not ideal but good enough to give us some data to work with.
By analyzing the results, it is clear that the Local Accounts Handler is the main culprit of the slow imports (the HD Wallet Accounts Handler imports the Local Accounts Handler which makes it slow by association).
As an exercise, I was able to shave off 1/3 of the loading time from the Local Accounts Handler by making the micro-eth-signer imports dynamic in 4d429a1. It shows that it is possible (and we could definitely do that for some other import paths there), but I'm not entirely sure we should go down that route.
I think we might be better off with the original solution to this, which is to use dynamic imports for handlers in the handlers array.
Here are the raw results of the handler import time analysis:
hardhat/v-next/hardhat/test/internal/builtin-plugins/network-manager/request-handlers/handlers-array.ts
Lines 13 to 27 in 92ceb85
I'm leaving this PR in draft as it was useful to me during the investigation. I don't necesarilly want to merge it as I think it would be a pretty flaky addition. We can discuss the next steps either here or in the original issue.