Skip to content

Review flutter attach performance #53313

Closed as not planned
Closed as not planned

Description

@xster

On a simple test, it takes ~8s to connect to an already running flutter observatory via flutter attach. Though ~3s was from cleaning up the devfs and closing the process.

Log gist at https://gist.github.com/xster/5becc4937c2cef8d5e84660d0601abd1

There's a 2397ms apparently pure Dart part in the middle of the process too.

We should optimize.

Activity

  1. added
    toolAffects the "flutter" command-line tool. See also t: labels.
    c: performanceRelates to speed or footprint issues (see "perf:" labels)
    a: existing-appsIntegration with existing apps via the add-to-app flow
    on Mar 25, 2020
  2. jonahwilliams commented on Mar 26, 2020

    @jonahwilliams
    Contributor

    It's initializing the frontend server and compiling the application code. This process is bootstrapped from the already compiled app if available.

  3. xster commented on Mar 27, 2020

    @xster
    MemberAuthor

    Ah, that sounds reasonable. You're saying that middle 2s+ would be drastically reduced in profile mode right?

  4. jonahwilliams commented on Mar 27, 2020

    @jonahwilliams
    Contributor

    Yeah, under profile mode we wouldn't attempt to compile anything - just connect

  5. jonahwilliams commented on Mar 27, 2020

    @jonahwilliams
    Contributor

    there also shouldn't be any devfs work in profile mode - so if that is case there is definitely a bug

  6. zanderso commented on Apr 15, 2020

    @zanderso
    Member

    @xster @jonahwilliams were either of you able to verify whether extra work was being done in profile mode?

  7. xster commented on Apr 15, 2020

    @xster
    MemberAuthor

    It was not. The purpose of flutter attach is to connect to a previously detached full-flutter app or to an add-to-app module in debug rather than profile mode.

  8. zanderso commented on Apr 16, 2020

    @zanderso
    Member

    Is there anything actionable left in this issue, or should we close it?

  9. xster commented on Apr 16, 2020

    @xster
    MemberAuthor

    I think we should profile whether any of the 8s spent during the attach can be improved on. If not, we should provide clearer output on what the tool is doing while the user's waiting.

  10. added
    P2Important issues not at the top of the work list
    on Aug 18, 2020
  11. jonahwilliams commented on Oct 12, 2020

    @jonahwilliams
    Contributor

    @xster would you be willing to try this again? I've landed a few optimizations to devFS initialization which should help. Preferably one that is uncached and one that is fully cached

  12. github-actions commented on Jul 11, 2025

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  13. locked as resolved and limited conversation to collaborators on Jul 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Important issues not at the top of the work lista: existing-appsIntegration with existing apps via the add-to-app flowc: performanceRelates to speed or footprint issues (see "perf:" labels)team-toolOwned by Flutter Tool teamtoolAffects the "flutter" command-line tool. See also t: labels.triaged-toolTriaged by Flutter Tool team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions