topic Re: 4.30 - Map very SLOW when adding 6000+ graphics in ArcGIS JavaScript Maps SDK Questions

4.30 - Map very SLOW when adding 6000+ graphics

michaelpoa — Tue, 22 Oct 2024 12:42:14 GMT

It seems like the map gets very slow when adding a lot of graphics at once via applyEdits. (addFeatures) We only fetch graphics based on an extent from our API. So this functionality is very important.

It looks like, when zooming in or out and new features are fetched and applied. It freezes or the apply will take 10+ seconds.

Timings:

timestamp 1. Before zooming out => fetching data (only 2000 assets)

timestamp 2. When zoomed out => fetched data => applied edits via ArcGIS API javascript

Its getting very slow. Why does it take so long for applyEdits to process new data (addFeatures),

Maybe there is like a condition: NO APPLY EDITS when USER INPUT / ZOOM / EXTENT change? When queuing all these actions, it gets very slow?

Codepen:

https://codepen.io/michaelk95/pen/RwXLPOa?editors=1000

StreamLayer has the same problems when adding too much at once.

Is it not possible to rewrite applyEdits to be faster? These are some simple pictures on a map, should not be complex I guess? In comparison with other map technologies, this could be a lot faster for client sided JS lib?

Thanks in Advance!

Re: 4.30 - Map very SLOW when adding 6000+ graphics

UndralBatsukh — Tue, 22 Oct 2024 16:19:41 GMT

Hi there,

Have you seen this sample - https://developers.arcgis.com/javascript/latest/sample-code/layers-featurelayer-large-collection/? This sample demonstrates how to add 100,000 features to a feature collection while keeping your app interactive.

I am not able to reproduce the behavior using client-side streamlayer. I used this app to test and it performs just fine - https://codepen.io/U_B_U/pen/xxvXqJP?editors=1000

Re: 4.30 - Map very SLOW when adding 6000+ graphics

SamEngel — Tue, 22 Oct 2024 20:51:20 GMT

Hi @michaelpoa! Looking at the codepen, I see what you mean about the long freezes. But when I try running a performance profile, I'm only seeing applyEdits() take a few hundred milliseconds. It seems like a lot of time is spent in:

the forEach() calls within applyDataToMap()
intersection
garbage collection

I noticed a couple of things that might be contributing:

On line 231, there's a Array.find() call within an Array.forEach() call. Maybe outside of the forEach() it'd be possible to construct an object/dict/Map to look up features by id?
In intersects(), the feature geometry is projected into view space. That projection can be expensive, and it will generate new geometry objects that are used once and then need to be garbage collected. Maybe it's possible to project the view extent into the graphic geometry's spatial reference instead? That could be done once, outside the loop.
If there's a way to avoid querying all the features, that will probably also help to reduce garbage collection time

Hopefully something in there is useful!