Skip to content

Offer options that balances embeddable Flutter load time with resource consumption #32946

Closed

Description

@xster

We should identify the right balance point between loading the embedding / vm / isolate / framework / userland element tree / resources in the tree based on each part’s load time vs its memory use.

This involves #32945 to audit cold init time and also auditing memory consumption.

Our recommended embedding strategy + default behaviors from APIs should be reasonably balanced between fast loading and memory usage.

Document alterations users can make given those APIs such as prewarming/keeping the vm only, prewarming/keeping the isolate. Flutter side APIs to flush parts of the tree when window is not visible.

Activity

  1. added
    frameworkflutter/packages/flutter repository. See also f: labels.
    engineflutter/engine related. See also e: labels.
    c: performanceRelates to speed or footprint issues (see "perf:" labels)
    a: existing-appsIntegration with existing apps via the add-to-app flow
    on May 18, 2019
  2. matthew-carroll commented on Jun 6, 2019

    @matthew-carroll
    Contributor

    This sounds like it might imply new APIs for such control? If so, those APIs probably sit at the basest level of the system and we should resolve these concerns ASAP. I imagine that this could impact bootstrapping behavior for the native system, as well as core APIs for all embeddings...

  3. xster commented on Jun 6, 2019

    @xster
    MemberAuthor

    I agree, this is the first task I'm looking at. I'm still not sure yet whether this involves just fixing bugs or our existing APIs can't offer the right degree of control for our users.

  4. xster commented on Jun 7, 2019

    @xster
    MemberAuthor

    In scope is to fix

    Screen Shot 2019-06-06 at 6 07 57 PM

    Whether by API changes or fixing bugs

  5. xster commented on Jun 15, 2019

    @xster
    MemberAuthor

    Part of the issue above is likely #26007

  6. goderbauer commented on Jun 17, 2019

    @goderbauer
    Member

    I am not sure I understand what this issue is asking for. Specifically, what's needed from the framework to fix this (since it has the framework tag)?

  7. xster commented on Jun 18, 2019

    @xster
    MemberAuthor

    The framework side of it will mostly be just #32871 (in making sure that there's a documented way of unloading things once the window is no longer attached).

  8. github-actions commented on Aug 26, 2021

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

  9. locked as resolved and limited conversation to collaborators on Aug 26, 2021
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

    a: existing-appsIntegration with existing apps via the add-to-app flowc: performanceRelates to speed or footprint issues (see "perf:" labels)engineflutter/engine related. See also e: labels.frameworkflutter/packages/flutter repository. See also f: labels.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions