You are not logged in

I just added bug #44156 as a dependency. jwe demonstrated the results of some code which turns off Variable Updating unless the user is at the top-level prompt. This had a significant positive effect on performance.

I would prefer to just not have the workspace variables refreshed. I don't see the refresh as a real useful feature as is. There are a probably better ways of displaying information, such as dialog boxes or strip charts or something else. Octave may not have those things right now, but sometimes it is better to not have something than have a less than optimal implementation of a feature.

Perhaps we should instead tie the refresh of the workspace to the pause() function. That way if someone wants to occasionally print information inside of a long batch file, they can do so with pause(0). That's much more efficient than free-streaming the characters to the screen. If one uses pause(0) at some rate that is more on the scale of human perception, I doubt the loss in CPU would be more than a fraction of a percent.

Perhaps your Windows system library is set up to utilize the parallel operation features of the Intel chip (MMX, SIMO, or whatever many names it has been called). The FFT is the perfect example of how to use the feature, just stack up all the butterflies and do four of them with one set of instructions. It is really hard to say what is happening without looking at the code itself.

Has the refreshing of the screen been removed with all the ensuing GUI changes?

This is weird, I'm still seeing very slow times for this fftfilt test loop in my Debian build, both CLI and GUI give total times of about 52-54 seconds.

However, if I test in a WinXP VM running on the same system, I get a test time of about 11.5 seconds in CLI mode and about 17 seconds in GUI mode. Closing the workspace view bumps it back down to 12.5 seconds.

Updating status to confirmed, lowering severity because closing the workspace view is an acceptable workaround, and if I remember the intended behavior was to show results in the workspace view as they are being calculated in long running scripts.

You're right. The slowdown isn't that dramatic, just a long test. Here are the results for my system:

Without GUI:

With GUI:

So it is about a 20% slow down. This is consistent with other similar time tests I've done. So maybe the refreshing of the text isn't the problem but more generally the way in which communication works between the GUI and the core.

Nonetheless, perhaps the graphics shouldn't be refreshed until the system becomes idle at the command line, i.e., after all is complete, a breakpoint is hit, etc.

Are you sure what you are seeing changes the time of the test? I see the same thing when running tests inside the GUI, but I don't observe any statistically significant difference in the time it takes the test to complete.