My impression is that the GCode viewer tab is responsible for the large memory usage, especially if you load a file that is more than a handful of MB large. And switching tabs doesn't change this, as once the file is loaded the GCode tab keeps the stuff in memory.
If you need to conserve memory, only using the camera is probably the best option.
If there is some memory leak you're triggering, this is of course something different. How large is the file you're printing? And how does the memory usage directly after the GCode Viewer tab finished processing the file compare to the 3.85GB you're seeing later?
I just tried a 30MB file and I get around 2GB RAM usage with this when opening the GCode Viewer. That seems to fit reasonable well with what you observed. There's a reason you have to click through a warning when opening large files in the viewer, this can easily crash the browser tab due to memory usage if you open files that are even larger.
The Octoprint viewer is significantly forked from the original GCodeViewer by now, as far as I understand. But I'm more surprised that a 470MB file actually loaded, anything above 100MB usually kills the browser tab for me.
Hi guys.
Opening up an old thread here, but I have this issue with a 167MB Gcode file.
Opens up fin in the above Gcode viewer, but crashes Octoprint when I try open it there.
In the Gcode viewer, it looks to take almost 4GB RAM in Chrome.
In Octoprint, the number just keeps going past my 16GB limit where it crashes the browser.
Any further help to get this resolved?
Busy with a 3 day print and follow it with the lines as I need to change filament at various lines in the code.
Because the gcode viewer is loading the whole file at once, and it builds up a collection of data about the file as it is parsed. This raw data is about 10x the file size, and then you have to add in the overhead that the browser/JavaScript engine adds in for each piece of data. So for really big gcode files, it's not really designed to be used for them. Without someone writing a new gcode viewer there's nothing you can do about it now.
This is why it will warn you if the file is too large, and will not automatically load it. By default this is set to 25MB I believe.
Thanks for the feedback.
No I understand the process.
I have found a spot in the Octolapse page that tells me the current layer, so I can keep an eye on that.
But I still have almost 24 hours before that happens...
Yes, this is one of the only times ever I think I will reply to a comment like this... proud to say we've worked on the memory usage of the gcode viewer.
Both myself & @JoveToo (on GitHub) spent some time analysing the memory usage and fixed some things.
In OctoPrint 1.8.0 the improvements are (I would describe) quite large. Try out the release candidates and see - I can open files 10x the size I could before.
