Skip to content

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

Open
mraleph opened this issue Mar 17, 2025 · 56 comments
Open

Potential analyzer regression in 3.7 / Flutter 3.29 release #60335

mraleph opened this issue Mar 17, 2025 · 56 comments
Assignees
Labels
area-dart-model For issues related to conformance to the language spec in the parser, compilers or the CLI analyzer. model-performance Performance/memory issues in analyzer/cfe P1 A high priority bug; for example, a single project is unusable or has many test failures type-performance Issue relates to performance or code size

Comments

@mraleph
Copy link
Member

mraleph commented Mar 17, 2025

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.

@a-siva a-siva added the legacy-area-analyzer Use area-devexp instead. label Mar 18, 2025
@pq pq added type-performance Issue relates to performance or code size P1 A high priority bug; for example, a single project is unusable or has many test failures labels Mar 18, 2025
@johnniwinther johnniwinther added model-performance Performance/memory issues in analyzer/cfe area-dart-model For issues related to conformance to the language spec in the parser, compilers or the CLI analyzer. and removed legacy-area-analyzer Use area-devexp instead. labels Mar 19, 2025
@VivienStreit
Copy link

VivienStreit commented Mar 19, 2025

With performance issues (Flutter 3.29.1, Dart 3.7.0)

[√] Flutter (Channel stable, 3.29.1, on Microsoft Windows [Version 10.0.22631.5039], locale en-CH)
[√] Windows Version (11 Pro 64-bit, 23H2, 2009)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Build Tools 2022 17.5.1)
[√] Android Studio (version 2024.1)
[√] VS Code (version 1.98.2)
[√] Connected device (3 available)
[√] Network resources

Initial Analysis Driver Timings

(name: <scheduler>, count: 0, elapsed: 0:00:00.000000, elapsedSelf: -0:00:12.965628)
  (name: analyzeFile, count: 403, elapsed: 0:00:12.963896, elapsedSelf: 0:00:12.915702)
    (name: libraryContext, count: 403, elapsed: 0:00:00.048194, elapsedSelf: 0:00:00.044308)
      (name: libraryCycle, count: 403, elapsed: 0:00:00.003886, elapsedSelf: 0:00:00.003886)
  (name: getUnitElement, count: 1, elapsed: 0:00:00.001732, elapsedSelf: 0:00:00.001438)
    (name: libraryContext, count: 1, elapsed: 0:00:00.000294, elapsedSelf: 0:00:00.000291)
      (name: libraryCycle, count: 1, elapsed: 0:00:00.000003, elapsedSelf: 0:00:00.000003)

Action in IDE

Multiple cycles of the following steps (in Android Studio):

  1. Addition of redundant line breaks
  2. File save (with format on save option enabled)

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

(name: <scheduler>, count: 0, elapsed: 0:00:00.000000, elapsedSelf: -0:00:04.232686)
  (name: getUnitElement, count: 54, elapsed: 0:00:00.005762, elapsedSelf: 0:00:00.002318)
    (name: libraryContext, count: 54, elapsed: 0:00:00.003444, elapsedSelf: 0:00:00.003316)
      (name: libraryCycle, count: 54, elapsed: 0:00:00.000128, elapsedSelf: 0:00:00.000128)
  (name: analyzeFile, count: 51, elapsed: 0:00:04.226924, elapsedSelf: 0:00:03.820578)
    (name: libraryContext, count: 51, elapsed: 0:00:00.406346, elapsedSelf: 0:00:00.353137)(bytesGet: 7311003, cycleCount: 51, libraryCount: 1020, libraryLoadCount: 1020)
      (name: libraryCycle, count: 51, elapsed: 0:00:00.053209, elapsedSelf: 0:00:00.053209)

Report

dart_analyzer_diagnostics_report.json


Without perf issue (Flutter 3.27.2, Dart 3.6.1)

[!] Flutter (Channel [user-branch], 3.27.2, on Microsoft Windows [Version 10.0.22631.5039], locale en-CH)
    ! Flutter version 3.27.2 on channel [user-branch] at C:\src\flutter
      Currently on an unknown channel. Run `flutter channel` to switch to an official channel.
      If that doesn't fix the issue, reinstall Flutter by following instructions at https://flutter.dev/setup.
    ! Upstream repository unknown source is not a standard remote.
      Set environment variable "FLUTTER_GIT_URL" to unknown source to dismiss this error.
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Build Tools 2022 17.5.1)
[√] Android Studio (version 2024.1)
[√] VS Code (version 1.98.2)
[√] Connected device (3 available)
[√] Network resources

Initial Analysis Driver Timings

(name: <scheduler>, count: 0, elapsed: 0:00:00.000000, elapsedSelf: -0:01:20.370275)
  (name: analyzeFile, count: 1, elapsed: 0:01:20.370275, elapsedSelf: 0:00:00.556503)
    (name: libraryContext, count: 1, elapsed: 0:01:19.813772, elapsedSelf: 0:00:09.978011)(bytesGet: 12089412, cycleCount: 973, libraryCount: 1603, libraryLoadCount: 1603)
      (name: libraryCycle, count: 1, elapsed: 0:01:09.835761, elapsedSelf: 0:00:01.189510)
        (name: fileState.refresh, count: 1766, elapsed: 0:01:08.646251, elapsedSelf: 0:00:32.796800)
          (name: getUnlinkedUnit, count: 1766, elapsed: 0:00:35.849451, elapsedSelf: 0:00:35.849451)

Action in IDE

Multiple cycles of the following steps (in Android Studio):

  1. Addition of redundant line breaks
  2. File save (with format on save option enabled)

Auto formatting almost instantaneous

Analysis Driver Timings

(name: <scheduler>, count: 0, elapsed: 0:00:00.000000, elapsedSelf: -0:00:02.672191)
  (name: analyzeFile, count: 25, elapsed: 0:00:02.672191, elapsedSelf: 0:00:02.628278)
    (name: libraryContext, count: 25, elapsed: 0:00:00.043913, elapsedSelf: 0:00:00.020618)(bytesGet: 3081425, cycleCount: 25, libraryCount: 500, libraryLoadCount: 500)
      (name: libraryCycle, count: 25, elapsed: 0:00:00.023295, elapsedSelf: 0:00:00.023295)

Report

dart_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.

@mraleph
Copy link
Member Author

mraleph commented Mar 20, 2025

cc @jensjoha

@VivienStreit
Copy link

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!

@sgrekhov
Copy link
Contributor

sgrekhov commented Mar 27, 2025

Hope this helps. I ran into the same issue and fixed it by removing the analysis_options.yaml file (with the content below) from one of the folders in my project — specifically, from the https://github.com/dart-lang/co19/tree/master/LanguageFeatures/Augmentation-libraries.

analyzer:
  enable-experiment:
    - augmentations
    - macros

As far as I remember, these experimental flags were introduced shortly before Dart 3.7.0. Do other people experiencing this issue have analysis_options.yaml files with any experimental flags in their projects?

Dart SDK version: 3.8.0-205.0.dev (dev) (Tue Mar 18 21:02:26 2025 -0700) on "windows_x64"

IntelliJ IDEA 2024.1.4 (Community Edition)
Build #IC-241.18034.62, built on June 20, 2024
Runtime version: 17.0.11+1-b1207.24 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11.0
GC: G1 Young Generation, G1 Old Generation
Memory: 4020M
Cores: 6
Non-Bundled Plugins:
  Dart (241.17890.8)
  com.intellij.ml.llm (241.18034.12)
Kotlin: 241.18034.62-IJ

@pq
Copy link
Member

pq commented Mar 31, 2025

@sgrekhov: did you have any plugins specified in your removed analysis options?

@sgrekhov
Copy link
Contributor

sgrekhov commented Apr 1, 2025

@sgrekhov: did you have any plugins specified in your removed analysis options?

No. Experimental flags only.

@mraleph
Copy link
Member Author

mraleph commented Apr 1, 2025

@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.

@mraleph
Copy link
Member Author

mraleph commented Apr 1, 2025

Here are the instructions to test:

Mac OS X (Apple Silicon)

SDK archive

  1. Close all IDEs. Make sure that no dart processes are running (check ps ax | grep dart and kill everything kill -9 $(ps ax | grep dart | awk '{print $1}'))

  2. Switch flutter to stable channel.

  3. Run flutter doctor and make sure that Flutter is at 3.29.X

  4. Go to the bin folder in Flutter SDK (e.g. by doing cd $(dirname $(which flutter))) and execute the following commands:

    $ cd bin/cache
    $ rm -rf dart-sdk
    $ curl -O https://storage.googleapis.com/vegorov-artifacts/dart-sdk-with-cl-419340-mac-arm64.zip
    $ unzip dart-sdk-with-cl-419340-mac-arm64.zip
  5. Start IDE, open your Flutter project and make sure that it is using dart binary from the Flutter SDK which we just updated. You can check ps ax | grep dart which should show dart binaries running from Flutter SDK.

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 Security > Developer Tools list system settings.

Windows (X64)

SDK archive

Note

Instructions below use PowerShell commands.

  1. Close all IDEs. Make sure that no dart processes are running. (e.g. Get-Process dart should not find anything)

  2. Switch flutter to stable channel.

  3. Run flutter doctor and make sure that Flutter is at 3.29.X

  4. Go to the bin folder in Flutter SDK (e.g. by doing Set-Location -Path (Split-Path -Path (Get-Command flutter).Path -Parent)) and execute the following commands:

    Remove-Item -Force -Recurse dart-sdk
    $ProgressPreference = 'SilentlyContinue'
    Invoke-WebRequest -Uri "https://storage.googleapis.com/vegorov-artifacts/dart-sdk-with-cl-419340-win-x64.zip" -Method "GET"  -Outfile dart-sdk.zip
    Expand-Archive dart-sdk.zip .
    Remove-Item dart-sdk.zip

    Warning: without $ProgressPreference = 'SilentlyContinue' download will be extremely slow!

  5. Start IDE, open your Flutter project and make sure that it is using dart.exe binary from the Flutter SDK which we just updated. You can check Get-Process dart | Format-List Path which should show dart.exe binaries running from Flutter SDK.

Linux (X64)

SDK archive

  1. Close all IDEs. Make sure that no dart processes are running (check ps ax | grep dart and kill everything kill -9 $(ps ax | grep dart | awk '{print $1}'))

  2. Switch flutter to stable channel.

  3. Run flutter doctor and make sure that Flutter is at 3.29.X

  4. Go to the bin folder in Flutter SDK (e.g. by doing cd $(dirname $(which flutter))) and execute the following commands:

    $ cd bin/cache
    $ rm -rf dart-sdk
    $ curl -O https://storage.googleapis.com/vegorov-artifacts/dart-sdk-with-cl-419340-linux-x64.zip
    $ unzip dart-sdk-with-cl-419340-linux-x64.zip
  5. Start IDE, open your Flutter project and make sure that it is using dart binary from the Flutter SDK which we just updated. You can check ps ax | grep dart which should show dart binaries running from Flutter SDK.

@petrnymsa
Copy link

@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.

I am interested.

Mac OS Apple Sillicon and Windows 11 Machine too.

@mraleph
Copy link
Member Author

mraleph commented Apr 1, 2025

@petrnymsa see instructions in this comment: #60335 (comment) I have now produced both versions of the SDK

@sgrekhov
Copy link
Contributor

sgrekhov commented Apr 1, 2025

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.

@bwilkerson
Copy link
Member

@scheglov For the crash report.

@pq
Copy link
Member

pq commented Apr 1, 2025

Experimental flags only.

Thanks, @sgrekhov! This is really interesting.

FYI + @stereotype441, @johnniwinther for context around possible augmentation library performance issues

@luis901101
Copy link

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.

@pq
Copy link
Member

pq commented Apr 1, 2025

Fantastic. That's encouraging. Thanks for the feedback @luis901101!

@mraleph
Copy link
Member Author

mraleph commented Apr 1, 2025

@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?

@luis901101
Copy link

@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.
To be more clear: today I started working as usual using latest stable Flutter 3.29.2/3.7.2 and the analyzer was struggling with completions, hightlitting and all that we already know... then I got the notification about this fix and I immediately downloaded the dart-sdk, following the instructions above, I killed Android Studio, killall dart, removed my current dart-sdk and replaced with the new one with the fix... after that I resumed working in my project and it was really nice...

@mraleph
Copy link
Member Author

mraleph commented Apr 1, 2025

@luis901101 Thanks! That's very reassuring. Please keep us posted if you observe any issues.

@luis901101
Copy link

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.

@nietsmmar
Copy link

Is it possible to test this SDK on linux?

@pq
Copy link
Member

pq commented Apr 8, 2025

@thanhdatvo
Copy link

Just a tip for vscode user: in order to test this dart-sdk, please update new sdk in settings.json and restart vscode

   "dart.sdkPath": "[DOWNLOAD_PATH]/bin/cache/dart-sdk",

@therybrian
Copy link

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

@bwilkerson
Copy link
Member

@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.

@luis901101
Copy link

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

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.

@pq
Copy link
Member

pq commented Apr 10, 2025

Yep I have experienced that “freeze" of MacOS Android Studio as well ...

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!

@saropa
Copy link

saropa commented Apr 11, 2025

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.

@bwilkerson
Copy link
Member

Regardless, the improvement in our IDE responsiveness has been dramatic.

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 dartdoc package, enabled all of the lint rules (by pasting them in at the end of the list in analysis_options.yaml) and ran the analyzer over the package. It nearly doubled the time to analyze the package (from ~2 seconds to ~4), but that's nothing like what you're seeing on your code base. I then ran a benchmarking tool we have to see whether I could identify a poorly behaving lint, but the worst behaving lint (avoid_redundant_argument_values) only used 141 ms of the total time.

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?

@diegotori
Copy link

diegotori commented Apr 11, 2025

@pq looks like your change won't make the Flutter 3.29.3 release that's coming up (based on this changelog). As a result, we won't be able to see it once that new Flutter version is released.

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 3.7.3 into Flutter?

@saropa
Copy link

saropa commented Apr 11, 2025

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

@changja88
Copy link

@saropa I applied your analyzer options, but still my android studio is super slow...
even alt+enter never show import options...  😭

@saropa
Copy link

saropa commented Apr 13, 2025

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!

@pedromassango
Copy link

Using the dart sdk from #60335 (comment) didn't work for me. What worked is removing all the content from the analysis_options.yaml.

@bwilkerson
Copy link
Member

One possibility related issue is that for this last period, Hot Reload + Hot Restart is effectively gone too.

Have you reported this elsewhere, or is this the first report of it?

What worked is removing all the content from the analysis_options.yaml.

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?

@pedromassango
Copy link

Did you have an empty file (or a file with only comments), or did you remove the file completely?

I just removed everything & kept the file

If you restore the contents do you see the same performance degradation?

Yes

analysis_options.yaml
analyzer:
  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

@bwilkerson
Copy link
Member

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.

@bwilkerson
Copy link
Member

I applied the provided analysis options to a non-Flutter package (dartdoc) and the time required to run dart analyze over the package did not change by any meaningful amount. I also applied the analysis options to a Flutter package (devtools) and again saw no significant change in performance. I will note that we have not seen any degradation of performance in either of those packages, but we have yet to be able to reproduce the performance problem locally, so I can't test the options against a package that's having problems to see whether it helps and if so why.

Despite not making any progress, I appreciate you providing us with the options you use.

@pedromassango
Copy link

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

@feinstein
Copy link

feinstein commented Apr 17, 2025

@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 dart fix --apply at the end of the generation and it gets totally stuck.

There are 25k+ linter issues reported, all of them are about converting " into ' and I think that's what it's slowing it down.

I made a version of my code that runs dart fix --apply after each file is generated and it took 22 minutes to complete on my Macbook Pro M2. But if I leave the dart fix --apply to the end (as it is in this version I sent you) it takes 1 hour to finish, taking 120% of my CPU.

Image

You can reproduce it by running:

dart run too/update_json_files.dart --convert

My dart environment:

Dart SDK version: 3.7.2 (stable) (Tue Mar 11 04:27:50 2025 -0700) on "macos_arm64"

I use puro for flutter version management and have Flutter 3.29.3 activated globally in my machine

@saropa
Copy link

saropa commented Apr 19, 2025

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

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)

Edit

Switched over to VSCodium, and it is immediately faster, https://vscodium.com/. Could it be the copilot / AI plugins killing performance?

Edit 2

Hot reload seems to now be working.

@davidmorgan
Copy link
Contributor

Not sure if it related, but the (clean) build_runner tasks are also now 4 - 5 mins.

I'm working on the known build_runner performance issues here, there will be a release soon that should help; I'll be interested to hear of any performance issues that remain after that.

@bwilkerson
Copy link
Member

@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 analyze over the files only takes 6-8 seconds on my machine, while computing the fixes takes over 5 minutes (that's when I was convinced that I could reproduce the problem). I haven't gotten any farther yet, but will continue to dig into it.

@feinstein
Copy link

Thanks, I appreciate the effort

@bwilkerson
Copy link
Member

Ok, with a lot of help from @jensjoha, I have confirmed that the problem is specifically related to running dart fix on large files with lots of diagnostics reported against it. He had several suggestions for ways to improve the performance in this case and I plan to work on applying those changes, but I thought I'd share a few workarounds that might be helpful.

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 analysis_options.yaml file in the directory containing generated code, where the file includes the options file in the parent directory and disables the lint that's generating all of these diagnostics.

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.

@feinstein
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-dart-model For issues related to conformance to the language spec in the parser, compilers or the CLI analyzer. model-performance Performance/memory issues in analyzer/cfe P1 A high priority bug; for example, a single project is unusable or has many test failures type-performance Issue relates to performance or code size
Projects
None yet
Development

No branches or pull requests