Browser Memory Useage

Using Octiprint on a 3B+ Pi.
Latest Octoprint.

Ender 3Pro.

Early 2015 MacBook Pro 2.9ghz i5 / 8GB
MacOS Mojave 10.14.3
Safari 12.0.3
Chrome 72.0.3626.109

When pointing a web browser to octopi.local to monitor my prints memory usage grows consuming upwards of 3.85 GB RAM according to Activity Monitor.

I have both the camera stream active and the gcode tab monitoring progress.

Anyway to cut down on the resource footprint? I really do not want to close the tab and have to reopen it when I want to check in on the print.

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?

What tab are you on when it grows like this?

I use the code tab the most, followed by the Control tab then the Temperature tab.

Current print file is 60MB and its a 12 hour print.

Gcode Visualizer is set to 500MB for Desktop.

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 issue is still opened :wink:

you can try your code here http://gcode.ws
and see if the consumption is the same.

I thought the was a fix for 100MB Gcode and 4GB to 400MB usage

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.

1 Like

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... :joy::rofl::+1:

Thanks again for the reply.

Curious if pretty gcode plugin can handle it any better?

1 Like

Any further development on this issue?
Been printing a lot of big files (120mb - 230mb) and still struggle to open the gcode to watch it.

Would be awesome if there could be a workaround or something for this...

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.

1 Like

This is great news! Thanks for the reply...

Not really one who installs RC versions, but I am really looking forward to the new release when it arrives!

Is there any ETA on it as yet?

No ETA, but should be soon. We've been through 5 rounds of release candidate and it's been working flawlessly for me.