GLVis
Significant increase in memory usage
Something happened between glvis-4.0 and glvis-4.1 that more than doubled the memory usage
If I do glvis -m mesh.000000 -g examples/sol.000000 (these are the saved files from mpirun -np 1 ex1p -m ../data/square-disc-p2.mesh), then I get the following memory usage:
- glvis-3.4 🠚 0.21 GB
- glvis-4.0 🠚 0.87 GB
- glvis-4.1 🠚 2.24 GB
- glvis-4.2 🠚 2.79 GB
- glvis-now 🠚 2.80 GB
Measured on my Mac with: ps x -o rss,vsz,command | grep glvis | grep '\/' | awk '{ print $1/1024/1024 }'
Maybe some of this is necessary, but it will be good to check if we can reduce it, since it impacts load time and the web version (see the recent MFEM AWS tutorial)
Data files:
#237 should take care of some of the low-hanging fruit.
Beyond that, I did some profiling of the mesh in question on a Linux system with massif. First, it seems that on Linux roughly 413MB is in use, instead of almost a full GB, so maybe some of the memory usage on Macs is related to the switch to Cocoa.
A general summary of allocations:
- Element/vertex/edge markers are a considerable chunk of that; the constituent lines make up roughly 80MB
- Text entry buffers for those markers are 40MB - the strings themselves are 32MB
- Ordering curve cones vertex data comes in at 80MB; the indices come in at 24MB
- Ordering curve cone lines come in at 16MB
- The mesh itself uses 32MB
Note that the markers are not generated for 3D meshes; I profiled a 3D stream file and the biggest memory hog was the ordering curve.
Things to try next
Generating markers could be deferred until the user requests that they be drawn.
At least some of this memory usage is the result of std::vector's resize behavior; if we can precompute and reserve the exact amount of buffer space we need, we can reduce some of these numbers.
Beyond this, we can use instancing/vertex "pulling" for the markers and cones, generating the final geometry in the vertex shader. This will probably take more work to set up the instancing infrastructure, and will likely be limited to modern OpenGL versions (OpenGL 3.1+ core/WebGL 2). On the flip side, this might be useful down the line for generating MFEM elements directly on the GPU.
Thank you so much for the detailed investigation @kanye-quest, this is significant improvement already and we really appreciate it!
The improvements in https://github.com/GLVis/glvis/pull/237 are now deployed and I notice significantly faster load time in both the Docker container and https://glvis.org/live/.
Thank you @kanye-quest 🚀