Mati, I've already made changes to more aggressively release entity references (see Be more aggressive about releasing Entity references in visualizers by mramato · Pull Request #3917 · CesiumGS/cesium · GitHub ). It will be in the next release.
Hey Matthew,
In my application, I'm using a CustomDataSource per datatype. I'm also loading only the portion of data that should be displayed and removing any data that should not (paging).
Roughly speaking, when a client pans or zooms the map, I remove the entities that does not fit the view and load (from the server) the new entities that does. I divide the world into tiles using my own tiling scheme,
but each data of such a tile is inserted into the same CustomDataSource.
So in my scenario, I have 2000 entities for instance at certain zoom level. When I zoom out and they are removed since they does not fit the map scale.
Then I zoom in again and those 2000 entities are once again streamed from the server.
Now I have 4000 entities in memory. And each time I zoom in and out it keeps growing.
I believe it would benefit me if you will release the ids once that primitive is returned.
If you make a change and need me to test it in my application I'd be happy to do it.
Thanks,
Mati
While you are correct that the entity reference is being held onto by the cached primitive id; this shouldn't be a factor if a data source is being removed (since that causes the visualizers and primitives to be destroyed, which will absolutely release all entity references). So Gianmaria's original problem can't be caused by the id reference.
It's possible that something else in the app is holding onto a reference (in Cesium or app code), so Gianmaria, if you can come up with reproducible test code (preferably Sandcastle), I'd be happy to take a look. It's also quite possible that the browser itself doesn't feel the need to reclaim that memory yet, in which case there's nothing we can really do about it. Unless some example code can show unbounded growth, it's not a leak and not really something you should worry about.
That being said, there's no reason we can't set the ids to undefined when the primitive is returned to the cache in order to help promote browser GC, but it's possible that doing so still won't have much affect.
I think you're right that this is the same issue as the one you had with Billboards. The PointGraphic uses a PointVisualizer to "translate" the entities into primitives, and it uses the same paradigm as the BillboardVisualizer, where the primitives are kept around to be reused. The Visualizers fail to release the primitive's reference to the entity when the entity is removed though, so the entity isn't eligible for garbage collection.
> Hey Gianmaria,
>
>
> I've tested my code with PointGraphics instead of BillboardGraphics and I can confirm it leaks the same way. The Entity instance is still exists in memory even after I have removed it.
> This is the modified example I've used to reproduce it.
>
>
>
> var viewer = new Cesium.Viewer('cesiumContainer');
>
>
> Sandcastle.addToolbarButton('Remove entity',function(){
> viewer.entities.removeById('myId');
> });
>
>
> var glowingLine = viewer.entities.add({
> id :'myId',
> name : 'This point is a suspect',
> position : Cesium.Cartesian3.fromDegrees(-75.59777, 40.03883),
> point :{
> pixelSize : 8
> }
> });
> After clicking 'Remove Entity' and taking a Heap Snapshot, the Entity instance still exists, with all of it properties. I guess because you use a great description they keep more memory on the Entity's instance.
>
>
> I have no solution for this problem and it frustrates me because it runs my browser out of memory when I do load tests 
>
>
> I Still honestly believe it's an issue in Cesium and hope it will be addressed
>
> Hi Mati,
>
>
> i have a large number of elements in the czml and none have the labels but i have a great description for each of them and point graphics property. Did you find any solution to the problem?
>
> Hey Gianmaria, I was just wondering, does your CZML creates a lots of Billboards / Labels ? I wrote a post recently (link) about
> a memory leak related to Billboards' removal that caused the removed entities to still exist in memory. So far since last week it had not been addressed yet by anyone of Cesium' team.
>
> If you can confirm this is the same problem, I hope the team will address the issue. For example, you can create a CZML without labels and billboards but a lot of polylines and see if after removeAll it still takes
> a lot of memory. Or if you are more into memory profiling you could try to reproduce it by my methods in my post..
>
>
> I really hope it is the same issue and that it will be addressed soon.
>
> Hi,
>
>
> as the title, my problem is that i need to deallocate memory after having removed a datasource of objects from cesium.
>
>
> Before loading a czml of objects i have about 140Mb of memory allocated, after i have 510Mb. But this is not the problem.
>
>
> The problem is that i want to return to the initial situation after removal of the datasource.
>
>
> If i use this line (Angular JS + Cesium):
>
>
>
>
> vm.cesiumConfig.cesiumInstance._viewer.dataSources.removeAll(true);
>
> The result is 400Mb of memory allocated.
>
>
> Any suggestions?
>
>
> Thanks Gianmaria
--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Well i suffer from the same problem in my application. billboard ,label and polyline are not no problem, but the model it can't removed from memory When I remove entities from a DataSource's EntityCollection. There is any solution?
