Repository navigation
Android slow cold start & slow warm start caused by Impeller #175577
Description
After upgrading production app from flutter 3.24.1 to flutter 3.32.5 we started seeing huge spikes in slow cold start and slow warm start times. After investigating it seems to be purely caused by Impeller rendering.
The issue is reproducible on flutter demo application.
Steps to reproduce:
- create sample app
flutter create test_app - run
flutter run --release - store this build somewhere for later use
- go into android/app/src/main/AndroidManifest.xml
- under
<application ... >add
<meta-data
android:name="io.flutter.embedding.android.EnableImpeller"
android:value="false" />
- run
flutter run --release - store that build somewhere for later use
- open terminal, run
adb logcat | grep Displayed - to benchmark install & run first build, see
Displayedtiming - Uninstall app, install second build, see
Displayedtiming - Repeat steps 9-10
In the tests I was conducting here are the timings:
Android 16 emulator 16kb:
With Impeller:
- +758ms
- +654ms
- +611ms
Without Impeller:
- +301ms
- +222ms
- +211ms
Android 14 emulator:
With Impeller:
- +790ms
- +739ms
- +694ms
- +641ms
Without Impeller:
- +1s29ms
- +673ms
- +286ms
- +274ms
Pixel 6 Android 16:
With Impeller:
- +581ms
- +606ms
- +613ms
Without Impeller:
- +674ms
- +601ms
- +661ms
Samsung Galaxy Z Flip 5 Android 15 OneUI 7.0:
With Impeller:
- +700ms
- +560ms
- +767ms
Without Impeller:
- +404ms
- +535ms
- +533ms
On top of that I have production data that shows certain devices being affected more than others. Such as:
- OPPO CPH2239
- Samsung Galaxy A12
- OPPO A57
In general devices with CPU cores cortex-A53 Seem to suffer the most after upgrade to impeller
Activity
[-]Android TTID is super slow caused by Impeller[/-][+]Android slow cold start & slow warm start caused by Impeller[/+]darshankawar commentedon Sep 18, 2025
@RelappsStudio Thanks for the report. Running on emulators in release mode for majoring performance could be deceptive. Does the same occur on physical devices as well consistently ?
Can you also check on latest stable as well if the reported behavior still occurs or improves the performance as compared to previous stable ?
michalmaca commentedon Sep 18, 2025
I have same experience on the latest stable. Tested on real device (Honor 10).
Without Impeller, start of the new sample app takes around 385ms.
With impeller, start of the same app takes around 1.5s.
Then warm starts in both cases takes around 350ms.
RelappsStudio commentedon Sep 18, 2025
After testing with Flutter 3.35.4 on channel stable here are results on real devices I have & can test.
Pixel 6 Android 16
With Impeller:
Without Impeller:
Samsung Galaxy ZFlip 5 Android 15:
With Impeller:
Without Impeller
There is a clear advantage when disabling impeller. And those are both still higher-end devices. I can only assume the problem is more visible on cheaper "bad" phones.
RelappsStudio commentedon Sep 18, 2025
I asked some of my friends to test on their devices.
Here's test from Pixel 3 XL Android 12, OpenGL
With impeller:
Without Impeller:
xiaomi note 7 android 11, OpenGL
With impeller:
Without Impeller:
RelappsStudio commentedon Sep 18, 2025
Samsung galaxy A33:
Impeller :
+818ms
+759ms
+785ms
+772ms
+699ms
+748ms
No impeller :
+585ms
+505ms
+495ms
+579ms
+564ms
+561ms
RelappsStudio commentedon Sep 18, 2025
HONOR 50 MagicOS 7.1 Android 13
impeller:
no-impeller:
darshankawar commentedon Sep 19, 2025
@RelappsStudio Thanks for the details. I tried with S10+ device running Android 12 and below are the logs for it:
The device I used uses OpenGLES renderer. Can you provide which renderer the tested devices run on ? Vulkan or OpenGLES ?
RelappsStudio commentedon Sep 19, 2025
Hey, just to confirm- the renderer is the one showed when you run adb shell dumpsys gfxinfo, right? In that case for Pixel 6 it would be Vulcan. Funnily enough when running both app with & without impeller both identify as Skia
I'll ask others if they can provide data for their devices
darshankawar commentedon Sep 19, 2025
I'll keep the issue open for team's tracking based on reported behavior.
11 remaining items
chinmaygarde commentedon Sep 22, 2025
This is likely related to the pipeline initialization and we have ameliorations planned where startup can proceed before all pipeline state objects have been initialized so these benchmarks are addressed.
But even on devices where pipeline initialization is a bottleneck, we have found that it completes before the VM is setup. Though, the reports here seem to indicate otherwise. Thanks for the additional data points. These are super useful.
In any of these reports, it would be useful to provide the client rendering API used. Specifically whether it is using OpenGL or Vulkan. You should be able to tell from a log that gets emitted at startup. Something like:
duynnnnnn commentedon Sep 23, 2025
@RelappsStudio I tried with Xiaomi Note 14 device running Android 15 and the logs:
With Impeller:
I/flutter (20902): [IMPORTANT:flutter/shell/platform/android/android_context_vk_impeller.cc(62)] Using the Impeller rendering backend (Vulkan).
09-23 17:51:07.741 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s889ms
09-23 17:51:46.138 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s175ms
09-23 17:51:53.874 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +776ms
09-23 17:51:57.304 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s313ms
09-23 17:52:06.163 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s225ms
09-23 17:52:10.879 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s197ms
09-23 17:52:16.448 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s209ms
09-23 17:52:20.816 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s238ms
09-23 17:52:25.398 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s577ms
Without Impeller:
09-23 17:55:01.307 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +1s461ms
09-23 17:55:13.672 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +608ms
09-23 17:55:16.867 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +500ms
09-23 17:55:19.595 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +505ms
09-23 17:55:22.280 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +425ms
09-23 17:55:25.317 1828 1945 I ActivityTaskManager: Displayed com.example.test_app/.MainActivity for user 0: +485ms
jonasbernardo commentedon Sep 25, 2025
I tested it using a Galaxy A12 that uses the Helio P35 processor. With Impeller disabled, my app takes 1.5 seconds to start, but with Impeller enabled, it takes 5.5 seconds to start from cold. Impeller doesn't support Helio P35, so those extra 4 seconds are just for the fallback to Skia, which makes it unfeasible to use Impeller in apps that have a large base of old phones, as is the case with most Android apps.
jonasbernardo commentedon Sep 25, 2025
here is an important part of the records, and attached I am sending the complete record, maybe this will help
09-25 02:38:40.282 1370 1406 I ActivityTaskManager: Displayed com.google.testing.helium.utp.android.companion.backdrop/.BackdropActivity: +2s290ms
09-25 02:39:38.136 1370 1406 I ActivityTaskManager: Displayed com.jonasbernardo.developer.planejamento_semanal/.MainActivity: +5s568ms
register impeller.txt
jonasbernardo commentedon Sep 25, 2025
brmrodrigues commentedon Oct 13, 2025
darshankawar commentedon Oct 14, 2025
Please avoid asking for updates and please read https://github.com/flutter/flutter/blob/master/docs/contributing/issue_hygiene/README.md#tldr
abdullah517 commentedon Aug 10, 2026
I’m seeing the same issue on an Infinix X6835, and I was able to reproduce a significant difference between Impeller enabled and disabled.
With Impeller enabled, my startup trace shows:
With Impeller disabled, the first frame rasterization is much faster (~1.38s).
I also captured startup timeline traces for both cases and shared both the Impeller-enabled and Impeller-disabled data with the Flutter engineer investigating my duplicate issue (#190829).
What caught my attention in the Impeller-enabled trace is that the raster thread spends a significant amount of time in repeated
ReactorGLES/LinkProgramoperations before the first useful frame is rasterized. Some of these operations take tens of milliseconds, with several around 90–110ms.The trace also shows a
SceneDisplayLagevent with 218 missed vsync transitions.With Impeller disabled, I don't see the same repeated
ReactorGLES/LinkProgrampattern, and the first useful frame is rasterized much earlier.I’m attaching/providing the startup info and timeline traces for both configurations so they can be compared directly.
Device: Infinix X6835
I’m sharing this as additional data for this issue since #190829 was marked as a duplicate of this issue.
the first 2 files are with impeller enabled
start_up_info.json
start_up_timeline.json
the last 2 files are with impeller disabled
start_up_info.json
start_up_timeline.json
fusilid commentedon Oct 13, 2026
Adding measurements that isolate one part of this: on entry-level GPUs the cost is almost entirely Impeller OpenGL ES compiling shaders before the first frame when the app's data directory is empty, so it lands hardest on the first launch after install.
Setup: Flutter 3.47.2 stable, release build, measured on AWS Device Farm. The automatic backend selection picked Impeller OpenGL ES on both devices:
Method: four launches per install, timed with
am start -WandreportFullyDrawn:pm clear(data wiped, compiled code kept)cmd package compile -m speed -f, thenpm clearTab A7 Lite, three runs per build (ms):
EnableImpeller=false)Compiling the app's code ahead of time (d) changes nothing, but wiping the data (c) brings back the whole cost. In logcat the render thread is silent for 2.6–2.9 s (Tab A7 Lite) and about 2.0 s (Tab A 10.1") between surface creation and the first frame. With data present, the same gap is about 75 ms. On the Tab A 10.1", the first launch after install went from 2721 ms (Impeller) to 954 ms (Skia).
Why it matters to us: we target entry-level Android phones (Tecno/Infinix/itel class) with a 3 s cold-start budget. Every new install pays this cost on its very first launch, which is the user's first impression, so for now we've opted out via
EnableImpeller=false. We'd like a supported way to avoid it before the opt-out is removed, for example deferring pipeline compilation until after the first frame, or compiling only what the first frame needs. Happy to run builds frommainon the same devices if that helps.