You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That really is a big difference between our runs, and I definitely think it would be disk-bound. For the above set of packages (not that different from your selection), it takes me around 50 sec to completely discover the tests.
I'll open a separate issue about that later then, thanks!
There is a lot of time spent in existsSync() which is checking each folder to see if it's a package (does it have pubspec etc.). It's possible that making this async and trying to do some in parallel will help.
There's also a lot in "self time" in discoverTestSuites but I'm not sure if this is reported correctly, or just confused because it's recursive?
Not sure what get is here, maybe the call fs.statSync(file).isFile()? I wonder if there is some redundance in fs.existsSync(file) && fs.statSync(file).isFile(), we could just do the stat (and set throwIfNoEntry to decide how to handle missing)?
There's also a seemingly slow foldLines somewhere inside the yaml parsing where we detect if a project is Flutter (for suiteSupportsCoverage). I wonder if we can make this faster (or if the string check is very past, but it back in front of the full parse, so at least it's faster for non-Flutter projects).
I decided to test with the entire SDK folder so I had more data in the profile, but I found another issue - not one you're hitting, so I've raised it separately at #5936, but something we need to fix all the same.
I've landed many improvements in #5937 that should significantly reduce disk access (and duplicate YAML parsing).
@FMorschel I'll push an updated pre-release shortly if you'd like to test it. The whole pkg folder came down from >9s to 1.3s on my machine, so I'm hopeful things will be much better for you.
@FMorschel I've published v3.129.20260226; I'd be interested to know what difference it makes (and I'd be interested in an updated extension host profile trace for the same as you captured above to see what's slowest now).
I did not convert all the disk access to async yet, because there was so much duplicated disk access that I thought it might not be necessary, however it's still an option depending on how the trace looks.
Thanks, that's a decent improvement but I think this still needs more attention.
Since I'm planning on a release and the existing changes are worthy of being in the release notes, I'm gonna resolve this one, but I've opened #5951 to take another look at both project discovery + test discovery in the next release too.
Activity
DanTup commentedon Feb 26, 2026
Thanks!
There is a lot of time spent in
existsSync()which is checking each folder to see if it's a package (does it have pubspec etc.). It's possible that making this async and trying to do some in parallel will help.There's also a lot in "self time" in
discoverTestSuitesbut I'm not sure if this is reported correctly, or just confused because it's recursive?Not sure what
getis here, maybe the callfs.statSync(file).isFile()? I wonder if there is some redundance infs.existsSync(file) && fs.statSync(file).isFile(), we could just do thestat(and setthrowIfNoEntryto decide how to handle missing)?There's also a seemingly slow
foldLinessomewhere inside the yaml parsing where we detect if a project is Flutter (for suiteSupportsCoverage). I wonder if we can make this faster (or if the string check is very past, but it back in front of the full parse, so at least it's faster for non-Flutter projects).DanTup commentedon Feb 26, 2026
I decided to test with the entire SDK folder so I had more data in the profile, but I found another issue - not one you're hitting, so I've raised it separately at #5936, but something we need to fix all the same.
DanTup commentedon Feb 26, 2026
I've landed many improvements in #5937 that should significantly reduce disk access (and duplicate YAML parsing).
@FMorschel I'll push an updated pre-release shortly if you'd like to test it. The whole
pkgfolder came down from >9s to 1.3s on my machine, so I'm hopeful things will be much better for you.DanTup commentedon Feb 26, 2026
@FMorschel I've published v3.129.20260226; I'd be interested to know what difference it makes (and I'd be interested in an updated extension host profile trace for the same as you captured above to see what's slowest now).
I did not convert all the disk access to async yet, because there was so much duplicated disk access that I thought it might not be necessary, however it's still an option depending on how the trace looks.
FMorschel commentedon Feb 26, 2026
Here is the new profile:
DanTup commentedon Feb 26, 2026
Thanks! How long in real time does it take now (when not profiling) compared to the original 50s?
FMorschel commentedon Feb 26, 2026
It is now around 19 seconds. A great improvement!
DanTup commentedon Mar 2, 2026
Thanks, that's a decent improvement but I think this still needs more attention.
Since I'm planning on a release and the existing changes are worthy of being in the release notes, I'm gonna resolve this one, but I've opened #5951 to take another look at both project discovery + test discovery in the next release too.