search

CesiumGS / cesium

An open-source JavaScript library for world-class 3D globes and maps :earth_americas:
https://cesium.com/cesiumjs/
Apache License 2.0
13.03k stars 3.51k forks source link

Development server memory skyrockets after changing shaders #12164

Open jjspace opened 3 months ago

jjspace commented 3 months ago

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.

javagl commented 3 months ago

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.

jjspace commented 3 months ago

@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