Is there a way to configure the number of cesiumWorkerBootstrapper workers

I have a Cesium app with many entities loaded and it is consuming a significant amount of memory. When I open the FF performance tab (about:performance) I see that there are up to 17 cesiumWorkerBootstrapper workers running. Not entirely sure what is running in each, but they are all using the same amount of memory so it makes me think that they are copies of the same code…probably some rendering threads. Is there a way to configure the number of workers? I assume each worker is creating a copy of the entities I’ve loaded into Cesium? Any help would be appreciated, thanks.


The workers are usually created to construct the geometry asynchronously so it doesn’t block the main thread - so they wouldn’t be holding onto a copy of the geometry (although you can confirm this by modifying the source code to make all entities synchronously created so that no workers are launched).

How much memory is your application using? And how many entities are you creating? What type of entities are they? Do they have textures?

The number and types of entities varies based on user inputs, but typically there are thousands of point entities, tens of polygons and a few textures. The entities themselves are not textured, just a few textures in the scene. I’ve seen memory consumption with each worker around 580MB, multiply that by 17 workers and add in other data structures in the application and total memory grows to 9GB-12GB. Sometimes when the application is idle the worker thread’s memory spikes. Not sure how to control whether they are created in a sync fashion so I can look into this, but the typical process being used is to add them to entity collections via the CustomDataSource object.


It’ll require a little bit of digging in the source code, but based on the type of entity, it would be created in one of the visualizer classes. Like here for example:

Each type of geometry has a different batch it’s added to, depending on its properties, that way entities can share resources and reduce memory use. So for example just a regular polygon, that’s colored, with no textures, and is not clamped to ground, would be created in the StaticGeometryColorBatch, so you’d just need to set this line to false:

The effect this would have is no workers will be created, at the cost of blocking the main thread when creating all the geometry. Alternatively, it may be easier to create a benchmark using the Primitive API which allows you to control the sync/async behavior so you can isolate if the workers are indeed the issue here or not. This is a good article for how to use the Primitive API:

What kind of application are you working on? Typically that scale is what 3D Tiles was created to solve, so you could have billions of points with efficient memory & speed, because only what’s visible in any given camera view is loaded.

Brief update on this issue. It seems that the number of these workers is correlated to the number of polygons being rendered, perhaps more so than other entities. I forgot about a country border layer consisting of almost 200 country border polygons, I removed that layer as a default and the number of workers dropped from 17 to 3. I’ll look through the links you supplied to see if I can fine tune this any further.


When drawing on Cesium 1.89…we have user tools on an app that allows drawing a rectangle (generally ArcType.RHUMB) on the map. It seems like every polygon we draw loads 500KB of worker classes (via cesiumWorkerBootstrapper.js). It seems eventually it will stop reloading these classes after every user draw but I’m not sure what the trigger is.

Any tips on if we can avoid this constant loading of workers (our network isn’t super fast). Is it related to the asynchronous properties you mentioned above?