-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Modifying "packages/flutter/lib/src/widgets/binding.dart" causes analysis that takes ~30s #60293
Comments
The linter takes a while, but to me it seems that linking is even bigger problem, happens every time the file structure changes significantly, i.e. adding a method. |
|
I disabled all lints, but I didn't see any real improvement in times. Here is the driver log showing approx 22s analysis after changing the name of the method in a single keystroke: And of the files reanalyzed, those with 3-digit millisecond times:
|
The call stack in the linter should never be deeper than the AST structure used to represent the code, but deeply nested code probably isn't as uncommon as one might hope. I'm not aware of anything we could do to reduce the depth of the call stack, other than rewriting our visitors to not use recursion, but I'm also not aware of a significant performance cost to having a deep stack. The number of files being reanalyzed is a function of the size of the library cycle being analyzed or relinked. Unfortunately, large library cycles are also not uncommon. We are working on reducing the amount of effort required to relink a library cycle after such a change, so we're hoping to be ale to make progress here. |
Not sure we can do anything about the size of the cycle in Framework :-/ About half of it is material + cupertino, which import the barrel files, but also the rest of the framework is not exactly being shy with importing barrel files. |
The Flutter team could reduce the use of barrel files in their own code by importing what they really depend on, but I don't think that's likely to happen and I don't have any evidence that that would reduce the size of the cycle. |
I'm busy right now with something else that should be done first, but I have an experimental implementation of fine-grained dependencies that significantly improve re-analysis times after incremental changes, like adding a method. It is not at the point where I would recommend using it. A simple operation below shows that re-analysis time goes from The workspace below consists of only Initial analysis
Change
Change
|
This sounds fantastic, I hope you're able to get back to it soon! 🙂 |
There are multiple performance issues coming up in #55281 which makes it a bit hard to track them (and their solutions), so I'm adding sub-issues for some individual issues that have been identified.
One issue is that modifying the file
lib/src/widgets/binding.dart
in the Flutter framework causes analysis that takes around 30 seconds. This was noted at #55281 (comment) by @knopp and I can reproduce myself:packages/flutter
folder in VS Codelib\src\widgets\binding.dart
file and wait for all analysis to completevoid h() {}
into the body ofabstract mixin class WidgetsBindingObserver
h
and typeg
)Some numbers from the timings:
I ran the CPU profiler over this but nothing stood out to me. A lot of the time is in linting, and the call stack gets very deep in the lint visitor, but I'm not sure if that's unusual (I don't know of this number of files is typical to be reanalyzed on a single change).
I've exported the CPU profile info from DevTools here: dart_devtools_2025-03-10_11_30_50.358.json
cc @bwilkerson @scheglov
The text was updated successfully, but these errors were encountered: