AxiophaseReading a menu photo in 1.8 seconds on a phone
Tong Learn reads Chinese menus, signs and screenshots with the camera — fully offline. A traveller holding up a phone in a restaurant won't wait long, so photo reading time matters. On a menu photo it was taking about 2.5 seconds. Here is how a single measured change brought it to 1.8.
Measure on the phone, not the desktop
Our first attempts to speed it up on a desktop machine found nothing useful: desktop CPUs behave too differently from a phone's mix of big and little cores. So we cross-compiled the OCR example for Android and ran it directly on the device (a OnePlus 13), varying only the number of threads.
The numbers
| Threads | Menu photo (453×676) | Web page (1280×2000) |
|---|---|---|
| 2 | 2.84–3.03 s | 1.83–1.87 s |
| 4 (before) | 2.45–2.46 s | 1.46–1.51 s |
| 6 | 2.15–2.28 s | 1.18–1.19 s |
| 8 | 1.78–1.83 s | 1.12–1.13 s |
Where the time goes
OCR runs in two stages: detection finds the text boxes, recognition reads each one. On the menu, detection took 0.4–0.5 s; recognition took 1.35–2.4 s. A menu is dozens of short lines, each recognised separately — exactly the kind of work that spreads well across cores.
The change
The app now opens the text reader with 8 threads. The translator keeps its own 4, so the next thing to check is that the live camera view stays smooth while both work at once.
Takeaways
- Profile on the target device. Desktop results didn't transfer.
- Split the pipeline and time each stage before optimising.
- The cheapest win is often a setting, not a new model.