You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While investigating performance issues on a user's map load time, I noticed that we were spinning up many more workers than tiles that could be viewed on the current viewport. This user's had 32 cores, so it was spinning up 16 worker threads (WorkerPool.workerCount = Math.max(Math.floor(browser.hardwareConcurrency / 2), 1);) but only actually using ~6 of them to parse tiles, and capping the workerCount at 6 reduced page load time by ~25%
@mapbox/gl-core question for the team:
Should we be using a different metric to set our worker count (for example viewport size/tile size, or hard cap it at an arbitrary number for machines with many cores) to reduce unnecessary slowdown caused by spinning up workers?
The text was updated successfully, but these errors were encountered:
While investigating performance issues on a user's map load time, I noticed that we were spinning up many more workers than tiles that could be viewed on the current viewport. This user's had 32 cores, so it was spinning up 16 worker threads (
WorkerPool.workerCount = Math.max(Math.floor(browser.hardwareConcurrency / 2), 1);
) but only actually using ~6 of them to parse tiles, and capping theworkerCount
at 6 reduced page load time by ~25%@mapbox/gl-core question for the team:
Should we be using a different metric to set our worker count (for example viewport size/tile size, or hard cap it at an arbitrary number for machines with many cores) to reduce unnecessary slowdown caused by spinning up workers?
The text was updated successfully, but these errors were encountered: