This commit is contained in:
parent
29b8b5307e
commit
7eb55e2a14
9 changed files with 204 additions and 18 deletions
26
docs/optimizing.md
Normal file
26
docs/optimizing.md
Normal file
|
@ -0,0 +1,26 @@
|
|||
# Optimizing Tutu
|
||||
|
||||
Topic Index:
|
||||
|
||||
- Time to first byte
|
||||
- Time to first draw: [Load size](#load-size)
|
||||
- CLS
|
||||
- Framerate: [Algorithm](#algorithm)
|
||||
|
||||
## Load size
|
||||
|
||||
The baseline for the load size is lowest 3G download bandwidth in 2s, typically 1.1Mbps (or ~137 kilobytes/s) * 2s = 274 kilobytes.
|
||||
|
||||
In another words there is 274 kilobytes budget for an interaction without further notice. Notice and progress are needed if the interaction needs than that.
|
||||
|
||||
The service worker can use 1 chunk of size.
|
||||
|
||||
## Algorithm
|
||||
|
||||
Don't choose algorithm solely on the time complexity. GUI app needs smooth, not fast. The priority:
|
||||
|
||||
- On the main thread: batching. Batching is usually required to spread the work to multiple frames.
|
||||
- Think in Map-Reduce framework if you don't have any idea.
|
||||
- On the worker thread: balance the speed and the memory usage.
|
||||
- Arrays are usually faster and use less memory.
|
||||
- Worker is always available on our target platforms, but workers introduce latency in the starting and the communication.
|
Loading…
Add table
Add a link
Reference in a new issue