Increase thread priority before engine init

[linxuebin1990]

Description

We get huge ANRs in not pure flutter app.
We found that 0.15% of the engine initialization took more than 10 seconds, every 10 million starts.

Fellow code show, engine init in ui thread. So Increase thread priority before engine init can reduce time cost

// shell/common/shell.cc
fml::TaskRunner::RunNowOrPostTask(
      shell->GetTaskRunners().GetUITaskRunner(),
      fml::MakeCopyable([&engine_promise,                                 //
                         shell = shell.get(),                             //
                         &dispatcher_maker,                               //
                         &platform_data,                                  //
                         isolate_snapshot = std::move(isolate_snapshot),  //
                         vsync_waiter = std::move(vsync_waiter),          //
                         &weak_io_manager_future,                         //
                         &snapshot_delegate_future,                       //
                         &unref_queue_future                              //
  ]() mutable {
        TRACE_EVENT0("flutter", "ShellSetupUISubsystem");
        const auto& task_runners = shell->GetTaskRunners();

        // The animator is owned by the UI thread but it gets its vsync pulses
        // from the platform.
        auto animator = std::make_unique<Animator>(*shell, task_runners,
                                                   std::move(vsync_waiter));

        engine_promise.set_value(std::make_unique<Engine>(
            *shell,                         //
            dispatcher_maker,               //
            *shell->GetDartVM(),            //
            std::move(isolate_snapshot),    //
            task_runners,                   //
            platform_data,                  //
            shell->GetSettings(),           //
            std::move(animator),            //
            weak_io_manager_future.get(),   //
            unref_queue_future.get(),       //
            snapshot_delegate_future.get()  //
            ));
      }));

Tests

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the contributor guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the C++, Objective-C, Java style guides for the engine.
• I read the tree hygiene wiki page, which explains my responsibilities.
• I updated/added relevant documentation.
• All existing and new tests are passing.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Did any tests fail when you ran them? Please read handling breaking changes.

• No, no existing tests failed, so this is not a breaking change.
• Yes, this is a breaking change. If not, delete the remainder of this section.
  • I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
  • I got input from the developer relations team, specifically from: Replace with the names of who gave advice
  • I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[linxuebin1990]

@liyuqian cc ?

[liyuqian]

The change looks reasonable. One challenging question is how to test and verify it. The expected improvement seems to be making 0.15% of engine initialization faster than 10 seconds, as previously observed by 10 million app startups in add-to-app scenarios on mobile devices. It is probably beyond our devicelab's capability to capture that signal reliably on mobile devices.

I wonder if we can simulate this in host machines with shell_benchmarks. Currently, it has a ShellInitializationAndShutdown benchmark which takes about 20ms for 1 iteration. Could we capture the improvement by running ShellInitializationAndShutdown for 1000 iterations and record the worst time? Could we spin num_cpu - 4 busy threads to artificially create some thread priority competition so we can observe this improvement more easily?

[linxuebin1990]

The change looks reasonable. One challenging question is how to test and verify it. The expected improvement seems to be making 0.15% of engine initialization faster than 10 seconds, as previously observed by 10 million app startups in add-to-app scenarios on mobile devices. It is probably beyond our devicelab's capability to capture that signal reliably on mobile devices.

I wonder if we can simulate this in host machines with shell_benchmarks. Currently, it has a ShellInitializationAndShutdown benchmark which takes about 20ms for 1 iteration. Could we capture the improvement by running ShellInitializationAndShutdown for 1000 iterations and record the worst time? Could we spin num_cpu - 4 busy threads to artificially create some thread priority competition so we can observe this improvement more easily?

OK, I will do measure it by ShellInitializationAndShutdown .

[linxuebin1990]

The change looks reasonable. One challenging question is how to test and verify it. The expected improvement seems to be making 0.15% of engine initialization faster than 10 seconds, as previously observed by 10 million app startups in add-to-app scenarios on mobile devices. It is probably beyond our devicelab's capability to capture that signal reliably on mobile devices.

I wonder if we can simulate this in host machines with shell_benchmarks. Currently, it has a ShellInitializationAndShutdown benchmark which takes about 20ms for 1 iteration. Could we capture the improvement by running ShellInitializationAndShutdown for 1000 iterations and record the worst time? Could we spin num_cpu - 4 busy threads to artificially create some thread priority competition so we can observe this improvement more easily?

We will verify this modification on Toutiao or Douyin in the near future.

[chinmaygarde]

IMO this is a fine low-risk change and beyond the capabilities of our current benchmark harnesses to measure.

[liyuqian]

Rerunning the Mac Host Engine test to see if it's just flaky. Agree that this is low-risk so landing without a test is reasonable. Of course, a test will always be appreciated as it can prevent accidental regressions, or capture similar performance issues caused by threads contention.