-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LoadPathCache scan takes a lot of time #277
Comments
I think something like this makes sense in general, and I'm even okay with a first version of it hardcoding |
I did some more profiling on different solutions:
EDIT: wrong number given at first |
Being able to exclude folders, particularly node_modules, would be super nice. I'm playing around with swapping yarn with pnpm in our monorepo and because of pnpm's nested symlinking structure it uses, it makes bootsnap absolutely choke. Startup time went from 4s to approx 1m with pnpm's structure. |
Probably extracting just a config option to exclude some directories from the linked PR would be pretty easy. |
Ack. I thought I implemented this already but apparently not. I'm traveling right now, so I don't have a lot of time, but I'll try to implement this soonish (might take about a week or so) |
If you have large non-ruby directories in the middle of your load path, it can severly slow down scanning. Typically this is a problem with `node_modules` Fix: #277
I'd appreciate if you could give this a try: #424 |
@casperisfine works wonderfully! thanks for taking a look at that so quickly! |
If you have large non-ruby directories in the middle of your load path, it can severly slow down scanning. Typically this is a problem with `node_modules` Fix: #277
I noticed that 2.5 out of 10 seconds of my application's startup time after requiring bootsnap is consumed by
Bootsnap::LoadPathCache::PathScanner.call
. By tracking the issue down, I found that it checks more than 150000 files thatDir.glob(path + ALL_FILES)
returns. Most of those files arenode_modules
, cache files and compiled assets.This is obviously unnecessary. By simply hardcoding skipping of those path I gained 20-25% less of application boot time. I was wondering how this can be parameterized without actually overwriting part of Bootsnap code.
"All-in" approach would be writing a C extension that would only return those paths that are not explicitly excluded from load path optimization instead of
Dir.glob
. I have some preliminary (working) result here: https://github.com/Shopify/bootsnap/compare/master...katafrakt:dir-walker?expand=1Lighter approach would be to just
next if excluded_paths.any? {|ep| absolute_path.start_with?(ep)}
to the block insideDir.glob.each
, but of course this would be a bit less performant (I don't know how much less).What are your thoughts about this issue?
The text was updated successfully, but these errors were encountered: