cesium icon indicating copy to clipboard operation
cesium copied to clipboard

Development server memory skyrockets after changing shaders

Open jjspace opened this issue 1 year ago • 2 comments

I'm not sure if this actually classifies as a memory leak or just memory runaway with conflicting processes.

Reproduce

  1. Run npm start to have the local server running
  2. Open any .glsl file under the Shaders directory
  3. Modify and save that file
  4. Observe memory usage by node skyrocket

My best guess is that the file watchers we have set up get stuck in a competing loop or something where they're repeatedly noticing changes, rebuilding the glsl -> js files, noticing JS changes -> rebuilding the JS -> triggering file changes in the shaders -> rebuilding -> repeat.

jjspace avatar Aug 28 '24 16:08 jjspace

If this shows up as a hard crash (some out-of-memory error) eventually, then I also noticed this occasionally recently. It also happened to me ~"when editing GLSL files", but I wasn't able (or did allocate the time) to pinpoint it to a specific workflow.

javagl avatar Aug 28 '24 16:08 javagl

@javagl if I notice it fast I usually kill it or Ctrl+C the process but if I don't then it does result in an OOM error. I assume it shouldn't be that hard of a fix I just also haven't spent any time digging into it yet Edit: I also noticed this gets waay worse if you save multiple times in quick succession. It seems our glslToJavascript is slow and you can kick off multiple of these async processes that overlap

jjspace avatar Aug 28 '24 17:08 jjspace