-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Potential analyzer regression in 3.7 / Flutter 3.29 release #60335
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
Comments
With performance issues (Flutter 3.29.1, Dart 3.7.0)
Initial Analysis Driver Timings
Action in IDEMultiple cycles of the following steps (in Android Studio):
Some formatting operations are almost instantaneous (i.e. line break removed), but most of them just never happen... Please, note that this is just an example of the slowness that is happening; most of the Dart tool chain seems to be very slow (like code highlighting, auto completion, auto import, etc..) Analysis Driver Timings
Reportdart_analyzer_diagnostics_report.json Without perf issue (Flutter 3.27.2, Dart 3.6.1)
Initial Analysis Driver Timings
Action in IDEMultiple cycles of the following steps (in Android Studio):
Auto formatting almost instantaneous Analysis Driver Timings
Reportdart_analyzer_diagnostics_report.json PS: With Flutter 3.29.1 and Dart 3.7.0, I occasionally encounter situations where the Dart Analyzer Diagnostics won't open, while syntax highlighting and formatting in the IDE become completely unresponsive. Hope this additional information might be helpful. |
cc @jensjoha |
Hello @mraleph, I wanted to check if my previous report was helpful. Please let me know if there's anything else I can do to assist! |
Hope this helps. I ran into the same issue and fixed it by removing the
As far as I remember, these experimental flags were introduced shortly before
|
@sgrekhov: did you have any plugins specified in your removed analysis options? |
No. Experimental flags only. |
@VivienStreit we (or more specifically @jensjoha) might have identified one possible source of the regression in 3.7, @pq has made a patch to try undo the offending change. If I produce a custom 3.7 SDK build for you would you be willing to test it out to see if it solves the problem for you? If yes - please let me know what platform to build SDK for. |
Here are the instructions to test: Mac OS X (Apple Silicon)
The Dart SDK is unsigned so you might hit some hiccups with Mac OS X security policies. You should be able to work around that by adding your IDE to Windows (X64)Note Instructions below use PowerShell commands.
Linux (X64)
|
I am interested. Mac OS Apple Sillicon and Windows 11 Machine too. |
@petrnymsa see instructions in this comment: #60335 (comment) I have now produced both versions of the SDK |
I just tried the updated SDK on Windows. I believe I have a good project for testing development tools (23,000+ files, thousands of which have intentional compile-time errors). I didn't follow the instructions above, but simply downloaded the SDK and replaced my own. There was an analyzer server crash on https://github.com/dart-lang/co19/blob/master/LanguageFeatures/Augmentation-libraries/augmenting_members_A04_t05_lib.dart. Yes, this is an experimental feature, but the analyzer server shouldn't crash anyway. Failure report issue-1.md. |
@scheglov For the crash report. |
Thanks, @sgrekhov! This is really interesting. FYI + @stereotype441, @johnniwinther for context around possible augmentation library performance issues |
I have tested the dart-sdk with the fix today (Mac OS Silicon, with Android Studio) in a project with over 1K files and it has worked as expected, syntax highlighting, formatting, auto completion, auto imports all very good. I will continue testing with other projects. |
Fantastic. That's encouraging. Thanks for the feedback @luis901101! |
@luis901101 just to double check - you get a better experience (e.g. faster completion, etc) than you were getting with Flutter 3.29 / Dart 3.7? |
Affirmative. |
@luis901101 Thanks! That's very reassuring. Please keep us posted if you observe any issues. |
I hope others also to test the sdk fix and share their experiences... in my case it has been really weird because Android Studio had the issue but VSCode not (or at least not so hard as Android Studio)... but I have read that other users had issues with VSCode... nevertheless today after downloading the sdk Android Studio has been working great. |
Is it possible to test this SDK on linux? |
Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/421341 |
Just a tip for vscode user: in order to test this dart-sdk, please update new sdk in settings.json and restart vscode
|
After testing I've noticed it's gotten much faster compared to before but what I'm getting now is the occasional Android Studio just freezing (on MacOS) and not being able to do anything until I force close it |
@jwren For visibility. As far as I'm aware, none of the changes we made to improve performance could cause Android Studio to freeze because they're all running in a separate process. I suspect that what you're seeing is a different problem. |
Yep I have experienced that “freeze" of MacOS Android Studio as well but it seems like a different issue because it has happened to me even when AS is working just fine with the dart-sdk fix. It's something apparently random and it has happened to me also with IntelliJ, so it's not only on AS. On VSCode no freeze ever happen. |
If you have any insights into how we can reproduce these freezes or any more context you could share, please open a bug on the flutter-intellij repo. Thanks! |
Going back to base principles, we decided to reset our analysis_options.yaml. Specifically, replacing # https://dart.dev/tools/linter-rules/all
include: all_lint_rules.yaml # causes slowdown? with include: package:flutter_lints/flutter.yaml We also deduplicated ~40 rules that simply replicated defaults, and these are our remaining lints (following our local coding style guide, included here for completeness): linter:
rules:
# Enabled Rules (ensuring base defaults)
always_declare_return_types: true
always_use_package_imports: true
# Disabled Rules (overrides)
avoid_catches_without_on_clauses: false
avoid_classes_with_only_static_members: false
avoid_positional_boolean_parameters: false
avoid_print: false
avoid_redundant_argument_values: false
constant_identifier_names: false
flutter_style_todos: false
lines_longer_than_80_chars: false
omit_local_variable_types: false
prefer_expression_function_bodies: false
prefer_relative_imports: false
public_member_api_docs: false
require_trailing_commas: false
sort_constructors_first: false
sort_pub_dependencies: false
unnecessary_async: false
use_super_parameters: false Perhaps this more idiomatic approach reduces the workload on the analyzer caused by a presumed recent change in rule parsing. Regardless, the improvement in our IDE responsiveness has been dramatic. We're not close to the previous responsiveness, but it no longer takes 5+ minutes to analyze a project. Will update if the situation changes. |
That's very interesting. I'm glad it helped, but I'm not sure why. It isn't the first time we've had a report that some set of lints was causing performance issues, but haven't yet been able to reproduce the problem. In response to this report I attempted again to reproduce the issue. I used the Unfortunately, I don't think you can run the benchmark tool unless you have a development environment where you can work on the Dart SDK. Are you working on an open source project that we could use to try to duplicate the experience? |
@pq looks like your change won't make the Flutter Since we shouldn't be overriding the Dart version in our Flutter install (Flutter doctor complains when you already have Dart installed), how are we supposed to consume Dart |
Hi @bwilkerson, I know this one is frustrating. Sorry, we're in-house, not open, but if it helps, the dev PCs have loads of spare CPU/GPU/RAM - rarely above 30%/15%/80% and are running on SSDs. The main app is 440k lines in 2200 .dart files. Analyzing remains fast today - never snappy, but now tolerable. Previously, the only fix (temporary) was the dance of flutter clean / flutter get / invalidate caches. I have been thinking the assumed exclusion list could be ineffective. I haven't yet A/B tested it, but a more aggressive analysis_options.yaml seems to have an impact. Here, we manually exclude files/folders that the analyzer is expected to ignore: analyzer:
exclude:
# === Generated Code ===
- "**/*.g.dart" # Exclude generated files
- "**/*.freezed.dart" # Exclude generated files
- "lib/generated_plugin_registrant.dart" # Exclude generated plugin registration
# === Build & Cache ===
- "build/**" # Exclude Flutter build output directory
- ".dart_tool/**" # Exclude Dart tool cache/generated files
- "bin/cache/**" # Exclude cache directory (if used)
# === Test Specific ===
- "test/.test_coverage.dart" # Exclude test coverage helper
# === Exclude native platform directories completely (no valid linters anyway)
- "android/**" # Exclude native platform code
- "ios/**" # Exclude native platform code
# === External packages (let them manage internally) ===
- "dependency_overrides/**" # Exclude 3rd party packages
# === System Resources (should not be necessary) ===
- "assets/**" # Exclude system fonts, images, static data
- "ktlint" # Kotlin linter - big file, no extension Cheers |
@saropa I applied your analyzer options, but still my android studio is super slow... |
That doesn't surprise me, unfortunately. Our results are mixed. One possibility related issue is that for this last period, Hot Reload + Hot Restart is effectively gone too. Doubly frustrating! |
Using the dart sdk from #60335 (comment) didn't work for me. What worked is removing all the content from the |
Have you reported this elsewhere, or is this the first report of it?
Did you have an empty file (or a file with only comments), or did you remove the file completely? If you restore the contents do you see the same performance degradation? If so, would you have the time to bisect the data in the file to help us narrow down what part of the file is causing the problem? |
I just removed everything & kept the file
Yes analysis_options.yamlanalyzer:
exclude:
- "**/*.g.dart"
- "**/*.freezed.dart"
- "**/*.gr.dart"
- "**/l10n/*.dart"
errors:
included_file_warning: ignore
# false positive when using Freezed
invalid_annotation_target: ignore
# Additional information about this file can be found at
# https://dart.dev/guides/language/analysis-options
# https://dart.dev/tools/linter-rules/all
linter:
rules:
always_declare_return_types: true
always_put_control_body_on_new_line: true
always_put_required_named_parameters_first: false
always_specify_types: false
always_use_package_imports: false
annotate_overrides: true
avoid_annotating_with_dynamic: false
avoid_bool_literals_in_conditional_expressions: true
avoid_catches_without_on_clauses: false
avoid_catching_errors: true
avoid_classes_with_only_static_members: true
avoid_double_and_int_checks: true
avoid_dynamic_calls: true
avoid_empty_else: true
avoid_equals_and_hash_code_on_mutable_classes: true
avoid_escaping_inner_quotes: true
avoid_field_initializers_in_const_classes: true
avoid_final_parameters: true
avoid_function_literals_in_foreach_calls: true
avoid_implementing_value_types: true
avoid_init_to_null: true
avoid_js_rounded_ints: true
avoid_multiple_declarations_per_line: true
avoid_null_checks_in_equality_operators: true
avoid_positional_boolean_parameters: true
avoid_print: true
avoid_private_typedef_functions: true
avoid_redundant_argument_values: true
avoid_relative_lib_imports: true
avoid_renaming_method_parameters: true
avoid_return_types_on_setters: true
avoid_returning_null_for_void: true
avoid_returning_this: true
avoid_setters_without_getters: true
avoid_shadowing_type_parameters: true
avoid_single_cascade_in_expression_statements: true
avoid_slow_async_io: true
avoid_type_to_string: true
avoid_types_as_parameter_names: true
avoid_types_on_closure_parameters: false
avoid_unnecessary_containers: true
avoid_unused_constructor_parameters: true
avoid_void_async: true
avoid_web_libraries_in_flutter: true
await_only_futures: true
camel_case_extensions: true
camel_case_types: true
cancel_subscriptions: true
cascade_invocations: false
cast_nullable_to_non_nullable: true
close_sinks: true
collection_methods_unrelated_type: true
combinators_ordering: true
comment_references: true
conditional_uri_does_not_exist: true
constant_identifier_names: true
control_flow_in_finally: true
curly_braces_in_flow_control_structures: true
dangling_library_doc_comments: true
depend_on_referenced_packages: true
deprecated_consistency: true
deprecated_member_use_from_same_package: true
diagnostic_describe_all_properties: false
directives_ordering: true
discarded_futures: true
do_not_use_environment: false
empty_catches: true
empty_constructor_bodies: true
empty_statements: true
eol_at_end_of_file: true
exhaustive_cases: true
file_names: true
flutter_style_todos: true
hash_and_equals: true
implementation_imports: true
implicit_call_tearoffs: false
implicit_reopen: true
invalid_case_patterns: true
join_return_with_assignment: true
leading_newlines_in_multiline_strings: true
library_annotations: true
library_names: true
library_prefixes: true
library_private_types_in_public_api: true
lines_longer_than_80_chars: false
literal_only_boolean_expressions: true
matching_super_parameters: true
missing_whitespace_between_adjacent_strings: true
no_adjacent_strings_in_list: true
no_default_cases: false
no_duplicate_case_values: true
no_leading_underscores_for_library_prefixes: true
no_leading_underscores_for_local_identifiers: true
no_literal_bool_comparisons: true
no_logic_in_create_state: true
no_runtimeType_toString: true
no_self_assignments: true
no_wildcard_variable_uses: true
non_constant_identifier_names: true
noop_primitive_operations: true
null_check_on_nullable_type_parameter: true
null_closures: true
omit_local_variable_types: true
one_member_abstracts: false
only_throw_errors: false
overridden_fields: true
package_api_docs: true
package_names: true
package_prefixed_library_names: true
parameter_assignments: true
prefer_adjacent_string_concatenation: true
prefer_asserts_in_initializer_lists: true
prefer_asserts_with_message: true
prefer_collection_literals: true
prefer_conditional_assignment: true
prefer_const_constructors: true
prefer_const_constructors_in_immutables: true
prefer_const_declarations: true
prefer_const_literals_to_create_immutables: true
prefer_constructors_over_static_methods: true
prefer_contains: true
prefer_double_quotes: false
prefer_expression_function_bodies: false
prefer_final_fields: true
prefer_final_in_for_each: true
prefer_final_locals: true
prefer_final_parameters: false
prefer_for_elements_to_map_fromIterable: true
prefer_foreach: true
prefer_function_declarations_over_variables: true
prefer_generic_function_type_aliases: true
prefer_if_elements_to_conditional_expressions: true
prefer_if_null_operators: true
prefer_initializing_formals: true
prefer_inlined_adds: true
prefer_int_literals: true
prefer_interpolation_to_compose_strings: true
prefer_is_empty: true
prefer_is_not_empty: true
prefer_is_not_operator: true
prefer_iterable_whereType: true
prefer_mixin: true
prefer_null_aware_method_calls: true
prefer_null_aware_operators: true
prefer_relative_imports: true
prefer_single_quotes: true
prefer_spread_collections: true
prefer_typing_uninitialized_variables: true
prefer_void_to_null: true
provide_deprecation_message: true
public_member_api_docs: false
recursive_getters: true
require_trailing_commas: true
secure_pubspec_urls: true
sized_box_for_whitespace: true
sized_box_shrink_expand: true
slash_for_doc_comments: true
sort_child_properties_last: true
sort_constructors_first: true
sort_pub_dependencies: true
sort_unnamed_constructors_first: true
test_types_in_equals: true
throw_in_finally: true
tighten_type_of_initializing_formals: true
type_annotate_public_apis: true
type_init_formals: true
type_literal_in_constant_pattern: true
unawaited_futures: true
unnecessary_await_in_return: true
unnecessary_brace_in_string_interps: true
unnecessary_breaks: true
unnecessary_const: true
unnecessary_constructor_name: true
unnecessary_final: false
unnecessary_getters_setters: true
unnecessary_lambdas: true
unnecessary_late: true
unnecessary_library_directive: true
unnecessary_new: true
unnecessary_null_aware_assignments: true
unnecessary_null_aware_operator_on_extension_on_nullable: true
unnecessary_null_checks: true
unnecessary_null_in_if_null_operators: true
unnecessary_nullable_for_final_variable_declarations: true
unnecessary_overrides: true
unnecessary_parenthesis: true
unnecessary_raw_strings: true
unnecessary_statements: true
unnecessary_string_escapes: true
unnecessary_string_interpolations: true
unnecessary_this: true
unnecessary_to_list_in_spreads: true
unreachable_from_main: true
unrelated_type_equality_checks: true
unsafe_html: true
use_build_context_synchronously: true
use_colored_box: true
use_decorated_box: true
use_enums: true
use_full_hex_values_for_flutter_colors: true
use_function_type_syntax_for_parameters: true
use_if_null_to_convert_nulls_to_bools: true
use_is_even_rather_than_modulo: true
use_key_in_widget_constructors: true
use_late_for_private_fields_and_variables: true
use_named_constants: true
use_raw_strings: true
use_rethrow_when_possible: true
use_setters_to_change_properties: true
use_string_buffers: true
use_string_in_part_of_directives: true
use_super_parameters: true
use_test_throws_matchers: true
use_to_and_as_if_applicable: true
valid_regexps: true
void_checks: true |
Thanks! I'll try using that on a local package to see whether I can reproduce the problem and post back here when I have information. |
I applied the provided analysis options to a non-Flutter package (dartdoc) and the time required to run Despite not making any progress, I appreciate you providing us with the options you use. |
I'm not surprised really, as people noted above, the issue is pretty random and even the fix mentioned by @mraleph is not working for everyone |
@mraleph I think I have a reproducible code for you. I am working on this repo: https://github.com/feinstein/google-i18n-address-dart And I created a tool that converts json files into dart files. The code runs There are 25k+ linter issues reported, all of them are about converting I made a version of my code that runs You can reproduce it by running:
My dart environment:
I use |
Ignore this one, sorry, the improvement was temporary. We are back to multi-minute analysis per code change. We can't clear the analysis options due to internal standards. Not sure if it related, but the (clean) build_runner tasks are also now 4 - 5 mins. As for the Hot Reload/Hit Restart being broken, we haven't found time to A-B test. (due to this VERY material impact on productivity)
Switched over to VSCodium, and it is immediately faster, https://vscodium.com/. Could it be the copilot / AI plugins killing performance?
Hot reload seems to now be working. |
I'm working on the known |
@feinstein Sorry for the long delay, but I can confirm that I can reproduce the behavior you're seeing. It just about has to be related to the production of fixes because running |
Thanks, I appreciate the effort |
Ok, with a lot of help from @jensjoha, I have confirmed that the problem is specifically related to running Obviously, the problem would be solved if the generator was changed to generate single-quote delimited strings in the first place. I'm guessing that that isn't an option or you would have already done so, but thought I'd mention it just in case I'm wrong. You might also consider temporarily not fixing those diagnostics and living with the generated code. The easiest way to do that would be to add an Unfortunately, I don't think this is the same problem that everyone is running into, so we'll continue to try to characterize the other performance issues so that we can work on fixing them as well. |
Good to know, thanks for the feedback! (and yes, converting between double to single quotes isn't a simple option for me, it can be done, but it will require some extra logic that can trigger edge cases, and these files are generated once in a blue moon, so the benefits don't justify the effort and risk). |
We have reports about potential regression in Flutter 3.29 / Dart 3.7 release which causes long analysis times.
If you are experiencing those please follow the instructions provided here to collect some information and post it here.
It would be especially helpful if you also collect a similar report using the previous version of Flutter / Dart which did not exhibit performance issues.
The text was updated successfully, but these errors were encountered: