Sisyphean memory management of Mesh3d on Chrome

[ntfrgl]

This is copied over from plotly/plotly.py#487.

---

I would like to share this peculiar behaviour in Mesh3d plots. Maybe it is somehow helpful in looking for memory management issues, although the data payload is imported from a file.

The code is from plotly/plotly.py#517 and it uses FigureFactory.create_trisurf() from the Python API (plotly 1.12.2) in offline mode within an ipython notebook. This leads to a regular oscillation in my RAM consumption when rendered inside Chrome, but not so for Firefox. The oscillation frequency seems to depend on the amount of interaction with the plot.

Chrome:

Firefox:

[etpinard]

Thanks for the report.

[monfera]

@ntfrgl Thank you for your detailed report!

It's expected that memory fluctuations may occur (object allocation and garbage collection cycles), and it's generally thought that Firefox is more sparing of memory use (Chrome spawns lots of OS level proceses), so the fluctuations and browser difference look reasonable.

However, some of the memory use is attributable to memory retainment (leaks) we're looking into, so the memory utilization might be lower, and more constant, for certain types of plots, once these fixes make it into the release: #724 #726

Memory fluctuation may not be a concern, yet I'm curious about what type of interactions the below statement cover. For example, simply rotating the man causes Chrome fluctuations, and when you stop orbiting the figure, then the sawtooth pattern goes away and the line becomes flat?

| The oscillation frequency seems to depend on the amount of interaction with the plot.

[ntfrgl]

The screenshot is not meant to be objective about total memory use, i.e. I had not killed all other processes and browser tabs. But what I can hear and see is that Chrome demands more power from the CPU and forces me to restart the kernel more often if numerous big plots are rendered in the same notebook. Also, this was originally not meant to be an issue of itself, but just a comment to plotly/plotly.py#487.

Regarding the fluctuations, you interpreted me correctly. Just after the first rendering, memory stays roughly constant, but depending on RAM congestion and interaction (rotate/zoom/pan), the sawtooth appears and intensifies. So the memory pattern is independent of the interaction in the short term, but a lot of interaction can lead to a regime shift. Generally, as it seems, the amplitude is lower when the wavelength is shorter. When interaction is halted for a long time, the amplitudes diminish, but the initial constant behaviour is not reached again.

I have no doubt that this pattern is caused by Chrome's GC heuristics, but the fluctuations seem unreasonably large to me. Looking forward to benefit from the reduced memory leaks!

[monfera]

@ntfrgl thanks for the additional, pertinent details! Indeed when there's a symptom we don't know off the bat if it's a standalone error, or relates to a known issue, or considered normal (given the ever current level of resource management sophistication).

It's useful to know that rotation, zoom, pan caused the fluctuation because these operations in theory shouldn't generate significant amounts of data (as with WebGL, it's mostly changing the 'model' uniform and a draw), I'll check to see if there's anything suspicious.

[monfera]

@ntfrgl @etpinard The above referred PRs and some more had been merged and bundled some time ago, which took care of some excessive memory use. Also, a level of memory use variability is still expected. This issue could be considered for closing.

[etpinard]

closing.