Open eduribas opened 2 weeks ago
By further testing I noticed that even if not running in isolates, by changing await command.executeThread();
to await command.execute();
in the code above, it still runs around 25% slower in release builds than in debug builds, in a Pixel 7 Pro.
This kinda feels like a Dart issue, I'm not sure what I'd be able to do about it. It must be hitting some performance penalty case for Dart release optimizations. I agree it's a terrible performance loss, and completely backwards to what you would expect.
This kinda feels like a Dart issue, I'm not sure what I'd be able to do about it. It must be hitting some performance penalty case for Dart release optimizations. I agree it's a terrible performance loss, and completely backwards to what you would expect.
Do you think it is related to this flutter issue: https://github.com/flutter/flutter/issues/140351 ?
As discussed in that issue, the usage of num
in computations is really problematic for the AOT compiler used for release builds.
I can take a look at num usage when I get a chance.
I suspect there is is something similar going on, but I don't know if it's num causing the performance hit with the AOT release build. num isn't used in the decoders and encoders.
The following simple code runs much slower in release build than in debug build on Android: