Memory leak possability

[wykks]

Memory leak possability

[Wykks]

Yes, inded there's still a small leak apparently. It's better in Angular 6 though. If you go to "Orders", I don't see any instance of MapComponent anymore. It's doesn't stack as much as in v5.

I'll see If I can do something about that, but it seems to be a bug in Angular itself

I don't think that it cause a "drastic drop in performance", it just eat more ram (and not forever in Angular 6 a least). These dead component should not eat any cpu at all, just ram (and not GPU ram since the canvas is 100% deleted). Not to mention that mapbox remove() fonction is called
https://github.com/Wykks/ngx-mapbox-gl/blob/master/projects/ngx-mapbox-gl/src/lib/map/map.component.ts#L212
https://github.com/Wykks/ngx-mapbox-gl/blob/master/projects/ngx-mapbox-gl/src/lib/map/map.service.ts
https://www.mapbox.com/mapbox-gl-js/api#map#remove
So It's just some ref to Angular component/service not doing much than taking some extra ram.

Edit : Welp I can reproduce the multiple stacking even in Angular 6 now... I'll try to do some things differently to see how Angular behave. But it's definitly a bug in Angular. ngx-mapbox-gl implements the lifecycle handled by Angular correctly.

[Wykks]

Okay one issue at a time 😅
The map is lagging after using it for a while ? I guess this should be reported to the mapbox-gl repo!
Check if you have the same issues when using raw demo of mapbox-gl (https://www.mapbox.com/mapbox-gl-js/example/simple-map/)

I'll try to see what's going on about Angular not destroying the map component, but I can't do much about the map lagging after a while.

[Wykks]

I'm not sure how it relate to this issue.
In the repro example here : https://stackblitz.com/edit/mapbox-with-lazyloading (not working anymore, but still) the map service is only provided in the map component.

I sometimes see people providing MapService in a module for unknown reason. It could be useful to add a warning in ngx-mapbox-gl if MapService is provided in a module.
MapService was actually private before this issue #19 (comment) . I should have made a more fine grained access to MapService...

[Wykks]

Interesting! Thanks to you repro, I was able to see it.

But, I can't repro in the version 2.0.0-beta.0 (https://stackblitz.com/edit/mapbox-with-lazyloading-n9mbbs)

So it's probably an issue with angular 5, not clearing lazy loaded components maybe.

[mapsgeek]

thanks, but actually i still can reproduce it. please bear with me for a bit
here are my steps

1. load the app, take an initial snapshot, size = 45 MB

2. navigate to customers, loads customers-list which contains the map, size = 55 MB

3. navigate back to home, size = 51 MB

As you can see compare the snapshot with the previous only the customerlist component " the map container " got garbage collected, the map Component and service still hanging there.

4. go back to customer, take a snapshot. size = 59 MB
and you can see that now the mapcomponent and service each has 2 instances allocated in the memory, because the one from previous navigation didn't get destroyed.

with each navigation you get a new instance added, accumulate in memory and GPU memory causing a drastic drop in performance when the app has layers and filters etc... , please tell me if i'm missing or misunderstand something

[mapsgeek]

the performance might not look dropped in the repo because we just loading the map, when you load vector-tiles layers and query the source features or rendered features with let's say nearly a 1000 feature with their geometry arrays, and apply filters to that, fitbounds, restyle etc .. , then the app copies and stacks instances of this on top of each other , the performance gets to hit.

i see what you are doing with the this.mapInstance.remove() , i tried doing the same as well calling the .remove() on the ngOnDestroy and even tried to set the map to undefined when i was using mapboxGL js raw, then i thought to give your module a shot and here we are with the same behaviour.

i was doubting angular but i see that it destroys the container component !, but now i have no clear vision which side to report to, so i thought to take your opinion here first since here we deal with both sides " angular " and "mapbox gl js " which might not be the case if reported in one of their repos

[Wykks]

So ngOnDestroy might not be called when the component are still there. Make sense. Will test that.

If this is the case, I may eat a lot more ram than just the extras instance of MapComponent/MapService. But still not hit the performance (at least, while the host does have free ram), because the cpu/gpu are not affected by that; the extras map are not doing do anything anymore.

[mapsgeek]

after a while the map goes from the 60fps smooth transitions to that lag and spikes in zoom in and out, this in chrome, the case goes worth in firefox and edge, and not in my app or angular only.
opening any example from the docs in firefox and i don't even get near to the 60fps chrome shows when the app is fresh, would you consider this a performance issue ? of course there's no continuous high cpu usage, just on zoom in and out, and for the gpu process in chrome task manager it gets close to 1GB in memory footprint and 350MB in gpu memory and the app tab can reach 800MB of memory footprint and those are all the info i can get since i don't have enough knowledge of memory to debug this further more

[mapsgeek]

thanks, sorry if i'm mixing things here but i think i'm getting this lag because of that no destruction thing !
i think i found a similar case but don't really understand the context of people trying to explain the issue, might help
well actually none of the components get to be destroyed, however the ngOnDestroy fires to the console and gets called
https://stackoverflow.com/questions/46984089/angular-dynamic-component-compiler-issue-memory-leak?rq=1

[Wykks]

(Note to self) http://plasma-umass.org/BLeak/

[mapsgeek]

don't provide the map service as a singleton in the shared module otherwise it will never get destroyed, instead provide in component providers... now i can die in peace

https://netbasal.com/angular-services-do-not-have-to-be-singletons-ffa879e62082

[mapsgeek]

hmmm you are right, well here's the full story i used to provide services in modules without thinking in the consequence like mentioned on that article, when i read the article i got a flash back that i used to do that with mapbox gl so that's what was going wrong, i didn't test well before i make that comment and depended on augury inspection to make sure that the component and service has been destroyed but then now when i ran heapSnapShot at different lifecycles and the service is only provided in component and it logs that it has been destroyed, the memory still have the map component and the service, i'm not an expert in debugging memory stuff but i click garbage collect button before i take a snap shot, i remember that once but not sure i tried the same process on vuejs and it was the same.
also a note: that last test was in development, do u have a reference if it should be done in production ?!
all what i was concerned about is my app being good in performance and that's all