It is someone's quarterly performance review and OKR to improve SLO. One such SLO is average load time. If you set such metrics as a goal, and financially reward people to do it, it's easy to meet the goal: arbitrary prune out the long tail, especially if the distribution of saved locations per user follows an Pareto/power law distribution.
They've since rolled back that experiment of payload sized limit, and instead used this number based limit. I guess it makes more a cleaner explainaton and internal documentation from a product sense this way as opposed to an arbitrary engineering limit.
The issue is still apathy and laziness from the engineers... they can have this per-request limits, but cache previously loaded pinnned locations, then incrementally append more to the list on subsequent requests. Instead, they attempt to reload the source of truth from the server everytime. There is a specific behavior where I see this is the case: they will load 3,000, you add another location which is now 3,001 locally, but after a few minutes they reconcile with the server and your local machine is back to 3,000. This is especially ironically considering the Google interview's emphasis on Dynamic Programming and building up a larger solution from previous solutions...
On Desktop, you can still load all your locations. There is some weird and intuitive behavior here how they reconcile edits to existing pin. The caveat on Desktop is that they will entire to render entire regions when there is too much (somewhere in the vicinity above 3,000 but below 8,000). I've noticed in recent weeks they've rolled out a quadtree
implementation where in a given rectangular region, they'd limit and cap how much saved locations they attempt to render, versus before where it would be seemingly depth-first until they reach the 3,000 limit.
It is someone's quarterly performance review and OKR to improve SLO. One such SLO is average load time. If you set such metrics as a goal, and financially reward people to do it, it's easy to meet the goal: arbitrary prune out the long tail, especially if the distribution of saved locations per user follows an Pareto/power law distribution.
They've since rolled back that experiment of payload sized limit, and instead used this number based limit. I guess it makes more a cleaner explainaton and internal documentation from a product sense this way as opposed to an arbitrary engineering limit.
The issue is still apathy and laziness from the engineers... they can have this per-request limits, but cache previously loaded pinnned locations, then incrementally append more to the list on subsequent requests. Instead, they attempt to reload the source of truth from the server everytime. There is a specific behavior where I see this is the case: they will load 3,000, you add another location which is now 3,001 locally, but after a few minutes they reconcile with the server and your local machine is back to 3,000. This is especially ironically considering the Google interview's emphasis on Dynamic Programming and building up a larger solution from previous solutions...
On Desktop, you can still load all your locations. There is some weird and intuitive behavior here how they reconcile edits to existing pin. The caveat on Desktop is that they will entire to render entire regions when there is too much (somewhere in the vicinity above 3,000 but below 8,000). I've noticed in recent weeks they've rolled out a quadtree implementation where in a given rectangular region, they'd limit and cap how much saved locations they attempt to render, versus before where it would be seemingly depth-first until they reach the 3,000 limit.