You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can try applying a Fingerprinter to the assets and skip the build if that passes.
As a last resort (though I ad suggested not to do this in part because of the complexity/duplication), we can teach the flutter_tester how to look up each asset from disk directly. The flutter_tool and flutter_test cannot share code however, so the logic would need to be duplicated and tested heavily so that it was kept in sync.
We should disable the flag by default to make the work opt-in. I'm concerned this is going to hurt discoverability of the feature - which is incredibly useful for real applications.
Also If we can switch back to the app-jit snapshots we'll get back the lost performance and then some.
One thing that might worth point out is, the real assets loading also take time in the test. Before this change, the assets loading is stuck at waiting future to finish. so the asset does not really load. Now, the assets does get loaded synchronously. which will actually take times to load. I am not sure whether the time increase is in building the assets or actually assets loading during test.
if it is the later, one other thing I can try will be making the assets load asynchronically. It will not spending time loading during the test unless user use tester.runAsync if they really want to test the assets load. What do you think?
The hello_world example that the benchmark runs on does not use assets, so ideally this change would not regress that time. Maybe we need one more short circuit for an empty asset manifest?
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.
Activity
jonahwilliams commentedon Apr 23, 2019
We can try applying a Fingerprinter to the assets and skip the build if that passes.
As a last resort (though I ad suggested not to do this in part because of the complexity/duplication), we can teach the flutter_tester how to look up each asset from disk directly. The flutter_tool and flutter_test cannot share code however, so the logic would need to be duplicated and tested heavily so that it was kept in sync.
Hixie commentedon Apr 23, 2019
We could also default to off, since most tests don't need this.
jonahwilliams commentedon Apr 23, 2019
I think there is some survivorship bias there, since assets haven't ever been supported in tests.
chunhtai commentedon Apr 23, 2019
A lot of test pass because the assets never load. The test will proceed with half rendered widget
It might cause flakiness without this patch. I will try to come up with a better solution
chunhtai commentedon Apr 26, 2019
Merged, let's see if this fixes it
Hixie commentedon Apr 27, 2019
Doesn't seem to have helped, but it's hard to tell for sure.
jonahwilliams commentedon Apr 27, 2019
We should disable the flag by default to make the work opt-in. I'm concerned this is going to hurt discoverability of the feature - which is incredibly useful for real applications.
Also If we can switch back to the app-jit snapshots we'll get back the lost performance and then some.
chunhtai commentedon Apr 29, 2019
One thing that might worth point out is, the real assets loading also take time in the test. Before this change, the assets loading is stuck at waiting future to finish. so the asset does not really load. Now, the assets does get loaded synchronously. which will actually take times to load. I am not sure whether the time increase is in building the assets or actually assets loading during test.
if it is the later, one other thing I can try will be making the assets load asynchronically. It will not spending time loading during the test unless user use tester.runAsync if they really want to test the assets load. What do you think?
jonahwilliams commentedon Apr 29, 2019
The hello_world example that the benchmark runs on does not use assets, so ideally this change would not regress that time. Maybe we need one more short circuit for an empty asset manifest?
Hixie commentedon Apr 30, 2019
(I've rebaselined the relevant tests, so that we can see further regressions; that doesn't impact the validity of this bug.)
chunhtai commentedon Apr 30, 2019
Merged, let's see if that improve
chunhtai commentedon May 1, 2019
I have seen the test performance drop down to normal since yesterday afternoon. Looks like we are good now. Closing this issue
github-actions commentedon Aug 30, 2021
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 -vand a minimal reproduction of the issue.