Performance hit with terminal

Development
1

I have been trying to figure out why my PrettyGCode pluging is having frame rate stuttering. At least part of the problem is that the terminal is taking up significant amounts of CPU even when the tab isn't displayed. Looking in the console, after a few seconds fancy terminal mode times out and is disabled and then it starts running ok. But after a few seconds fancy comes back on and my frames drop again.

Is it possible, preferably in code, for me to disable the terminal while the tab isn't displayed? Or at least disable fancy terminal functionality?

Terminal: Detected slow client (needed 808ms for processing new log data), disabling fancy terminal functionality
2

Or, this could become a core feature, like disabling the webcam when the tab is selected.

Theoretically possible for you to override using monkey-patching the OctoPrint code, but it's generally far better to do this cooperatively.

I can see this being overall beneficial, since I reckon the terminal does slow things down - if you've observed a performance issue, lets get it fixed!

3

I forgot to mention, PRs would be great :slightly_smiling_face:

But don't feel obliged, if you can't do it open an issue so we don't forget it.

4

My plugin has that under advanced tab - so please try


5

I wound up trashing fancy terminal. Extremely buggy, after a minute or so of watching it, all the text disappears and won't come back etc. deleted it and no more issues.

6

I made a change to disable the terminal processing when the tab is inactive. It did help, but didn't totally fix the performance issue I am having.

I'll submit a PR with the change once I have finished my tests.

7

When running octoprint in Firefox something is totally killing it - Im trying to narrow it down and will send som MR in when I find some good solutions

8

I'm using Chrome. I think I've tracked it down to something making a lot of expensive changes to the DOM but I don't know what yet.

9

Im trying with this:

So far the "tooltip-inner" in gcode is updating like crazy

10

I general there is so much updating due to knockout bindings that should be paused (http://www.knockmeout.net/2011/04/pausing-notifications-in-knockoutjs.html) in some way or another - for instance " Filament (Tool x)" section is being updated many times a second - even nothing is printing etc.

11

That's an interesting article @Laze. I could see that being beneficial in a lot of places.

12

Its very nice - its NOT a way I would recommed monitoring for changes in a produciton enviroment but for debugging its awesome - I use this one which tells you what item is being tampered with in the entire body - its quite a busy UI and as you can see alot of printing related stuff is being updated although nothing is being printed

// Select the node that will be observed for mutations
const targetNode = $('body')[0];

// Options for the observer (which mutations to observe)
const config = { attributes: true, childList: true, subtree: true };

// Callback function to execute when mutations are observed
const callback = function(mutationsList, observer) {
    // Use traditional 'for loops' for IE 11
    for(const mutation of mutationsList) {
        if (mutation.type === 'childList') {
            console.log('A child node has been added or removed.',mutation);
        }
        else if (mutation.type === 'attributes') {
            console.log('The ' + mutation.attributeName + ' attribute was modified.',mutation);
        }
    }
};

// Create an observer instance linked to the callback function
const observer = new MutationObserver(callback);

Run:
observer.observe(targetNode, config);

13

I have been doing some profiling (primarily on Chrome). After disabling the Terminal processing, when printing the Status dialog, the temperature tab and the idle stock GCode viewer all take up more processing than my 3d rendering. Primarily in the fromCurData() callbacks and ko.observable. That is with only the Status actually visible.

And that is pretty much all the tabs I have. So even if I could fix those any other plugin that isn't designed to "idle" could still cause hitches. I am starting to think getting smooth rendering isn't really going to be possible.

14

I would think if a solution was found to do this for plugins it would benefit all the developers and they could implement easier if given an example. I personally would love to see this, because my PlotlyTempGraph plugin I think might be impacted as well, as it reacts to that callback to graph the temps. I'd rather not take up resources if they aren't on that tab.

15

It wouldn't hurt to have some best practices. Like not doing processing if the tab is inactive. All I did for the terminal was this in fromCurData():

if(!tab.active)
   return;

But it isn't that easy for the other plugins I mentioned (except the gcode viewer). The Temp graph won't draw correctly if it misses temp updates. And the Status window should update ASAP but be more intelligent about changing things. Even that might not be easy to change since (like you pointed out) other plugins could be observing it and might be relying on the updates.

In my case I am thinking about changing my plugin to use the OctoPrint API rather than the plugin interface. That way I can better control what is updating when.

16

That's an interesting idea. I would think for Pretty GCode that watching print progress for the lines would be trickier with that approach for staying "in sync".