Page MenuHomePhabricator

Test performance of nearby feature on low-end devices
Closed, ResolvedPublic

Description

Via T315547: Add an auto-refresh mechanism to the nearby feature we added an auto-refresh feature. The way it's currently implemented means it can potentially pile up hundreds if not thousands of nearby points. Every time the map is moved or zoomed up to 50 new points are added. (Usually much less when the map still shows parts of the previous area.) The only situation points are removed is when the zoom level is changed multiple steps in or out. The threshold for this is currently >3 steps.

Task:

  • Find out how much the browser slows down when there are thousands of nearby points.
  • If possibly, test with a low-end device like a tablet.
  • Find a sweet spot where it starts to feel bad for the user.

Event Timeline

This benchmark was performed by duplicating 50 real-world markers equally, then to distribute the markers throughout the map, their coordinates were chosen at random from the map's bounding box. The frame rate was determined using Chrome's built-in FPS meter while crudely moving around in the map. Throttling was handled through Chrome's built-in CPU throttling mechanism.

CPU: Intel Core i5-8265U @ 1.60GHz
OS: Windows 11 (in "Best performance" mode)

# of MarkersFPS (without CPU Throttling)FPS (with CPU 4x Slowdown)
05958
1,2504617
2,5002713
3,7501810
5,000140

I would use a maximum of 2,500 markers for faster machines and 1,250 markers for slower machines.

Additional notes:

  • Note there is no need to guarantee a smooth frame rate (that would be anything close to 60 FPS). What matters is how it feels. 15 FPS start to feel like a stop motion animation, but are still very much acceptable for our use case.
  • A limit of 1000 points sounds like a good starting point.
  • To collect that many points you have to move and zoom the map 50 to 100 times.
  • Maybe we don't need to do anything. When the user notices a slowdown, all they need to do is to disable the nearby feature.