Confirm
975
edits
Changes
Create page with default dispatcher text
This guide will help Fenix developers working on front-end code (i.e. Kotlin/Java) produce code which is as performant as possible – not just on its own, but in terms of its impact on other parts of Firefox. Always keep in mind the side effects your changes may have, from blocking other tasks, to interfering with other user interface elements.
== Avoid blocking on the main thread ==
TODO
== Think carefully before optimizations using background threads ==
Concurrency is complex so be careful before introducing it! Even getting the thread pooling correct is challenging. TODO
== Dispatchers.Default is not a good default ==
When a task needs to be done on a background thread but it's not an IO operation, it frequently gets added to the default coroutine dispatcher, <code>Dispatchers.Default</code>. However, '''this is an anti-pattern''': if the default dispatcher's task queue is full, newly added tasks must wait for earlier tasks to finish before executing. '''This is a problem if your task needs to return a result (to the user/UI) quickly''' and the running tasks are slow: for example, if the user clicked a button and you want to show them content in response, they may end up waiting on unrelated tasks. Note: this problem is exacerbated on 2-core devices where only two tasks can execute simultaneously.
In general, <code>Dispatchers.Default</code> should only be used for computationally intensive tasks where tasks are FIFO priority or equal priority (this doesn't come up much in Android). It'd be much less misleading if it were named <code>Dispatchers.Computation</code>.
As for what to do if the default dispatcher is not a good fit, there's no one-size-fits-all solution. To choose the right threading scheme, it's important to understand your options: learn what each of the Dispatchers are intended for, what mechanisms they use to manage that, and their implications. Here are some additional considerations:
* <code>Dispatchers.IO</code> is often a much better default choice than the default dispatcher if your code does not produce many simultaneous tasks – which could generate many new threads – because it'll re-use existing threads.
* Avoid creating a dedicated thread or thread pool unless it's strictly necessary: each new thread costs the system resources
If you have questions about what the appropriate threading strategy is, please ask the perf team!
== Avoid blocking on the main thread ==
TODO
== Think carefully before optimizations using background threads ==
Concurrency is complex so be careful before introducing it! Even getting the thread pooling correct is challenging. TODO
== Dispatchers.Default is not a good default ==
When a task needs to be done on a background thread but it's not an IO operation, it frequently gets added to the default coroutine dispatcher, <code>Dispatchers.Default</code>. However, '''this is an anti-pattern''': if the default dispatcher's task queue is full, newly added tasks must wait for earlier tasks to finish before executing. '''This is a problem if your task needs to return a result (to the user/UI) quickly''' and the running tasks are slow: for example, if the user clicked a button and you want to show them content in response, they may end up waiting on unrelated tasks. Note: this problem is exacerbated on 2-core devices where only two tasks can execute simultaneously.
In general, <code>Dispatchers.Default</code> should only be used for computationally intensive tasks where tasks are FIFO priority or equal priority (this doesn't come up much in Android). It'd be much less misleading if it were named <code>Dispatchers.Computation</code>.
As for what to do if the default dispatcher is not a good fit, there's no one-size-fits-all solution. To choose the right threading scheme, it's important to understand your options: learn what each of the Dispatchers are intended for, what mechanisms they use to manage that, and their implications. Here are some additional considerations:
* <code>Dispatchers.IO</code> is often a much better default choice than the default dispatcher if your code does not produce many simultaneous tasks – which could generate many new threads – because it'll re-use existing threads.
* Avoid creating a dedicated thread or thread pool unless it's strictly necessary: each new thread costs the system resources
If you have questions about what the appropriate threading strategy is, please ask the perf team!
