Skip to content

Fix performance problems of flutter test --experimental-faster-testing #146603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
derekxu16 opened this issue Apr 10, 2024 · 6 comments
Open

Fix performance problems of flutter test --experimental-faster-testing #146603

derekxu16 opened this issue Apr 10, 2024 · 6 comments
Labels
P2 Important issues not at the top of the work list team-engine Owned by Engine team tool Affects the "flutter" command-line tool. See also t: labels. triaged-engine Triaged by Engine team

Comments

@derekxu16
Copy link
Contributor

The performance of flutter test --experimental-faster-testing is currently not ideal when running a large number of test files because the Lightweight Engines spawned when using this strategy get blocked from shutting down by open ReceivePorts. This was my latest attempt to ensure that all channels, and thus all ReceivePorts, get closed on the spawned isolates: d560cf4, but this commit did not fix the problem. So, we either have to determine what other changes need to be made in order to ensure that all ReceivePorts get closed on spawned isolates, or alternatively we need to add a new Engine API that can forcibly kill spawned Lightweight Engines.

@derekxu16 derekxu16 added tool Affects the "flutter" command-line tool. See also t: labels. engine flutter/engine repository. See also e: labels. labels Apr 10, 2024
@derekxu16
Copy link
Contributor Author

cc @a-siva

@a-siva
Copy link
Contributor

a-siva commented Apr 10, 2024

//cc @jonahwilliams would you be the right person to help out Derek here ?

@jonahwilliams
Copy link
Member

@derekxu16 are these package:test send/receive ports? if so have you talked to any of the package:test maintainers yet? I can look at it a bit but I'm not very familiar with the work.

@huycozy huycozy added the waiting for customer response The Flutter team cannot make further progress on this issue until the original reporter responds label Apr 11, 2024
@jonahwilliams jonahwilliams added team-engine Owned by Engine team and removed waiting for customer response The Flutter team cannot make further progress on this issue until the original reporter responds engine flutter/engine repository. See also e: labels. labels Apr 11, 2024
@derekxu16
Copy link
Contributor Author

There was some discussion with the package:test maintainers here: https://chat.google.com/room/AAAA3-KvHNw/_Ng7rX3hbHk. Nate's last message indicated that package:test currently forcibly kills spawned isolates when they are done running test code, and he doesn't know whether or not the spawned isolates would shut down by themselves if the force-killing logic was removed. When I get the chance, I can check what happens if the force-killing logic is removed from package:test.

@jonahwilliams jonahwilliams added P2 Important issues not at the top of the work list triaged-engine Triaged by Engine team labels Apr 22, 2024
@natebosch
Copy link
Contributor

and he doesn't know whether or not the spawned isolates would shut down by themselves if the force-killing logic was removed.

They do in the typical case.

After some more thinking, though, I got worried about removing the kill() call. I think it might be in place as a resource optimization. Nothing breaks when I remove it - but if some test patterns are commonly holding resources which keep test isolates running don't know if it could become a noticeable performance issue.

dart-lang/test#2198 (comment)

@aam
Copy link
Member

aam commented May 8, 2024

The culprit of slow performance seems to be the fact that all dart code for all tests in one combined dill file for all concurrently-running dart isolates spawned in flutter_tester runs on a single one and the same platform thread. So effectively we end up running all the tests on a single thread, not taking advantage of possible paralellization.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 Important issues not at the top of the work list team-engine Owned by Engine team tool Affects the "flutter" command-line tool. See also t: labels. triaged-engine Triaged by Engine team
Projects
None yet
Development

No branches or pull requests

6 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy