bugGNU Octave - Bugs: bug #39646, intermediate workspace display...

 
 

bug #39646: intermediate workspace display overload when executing 'test'

Submitted by:  Dan Sebald <sebald>
Submitted on:  Thu 01 Aug 2013 05:53:37 PM UTC  
 
Category: GUISeverity: 2 - Minor
Priority: 5 - NormalItem Group: Performance
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 10 Feb 2014 05:56:26 AM UTC, comment #8:

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.

Dan Sebald <sebald>
Thu 06 Feb 2014 01:42:15 PM UTC, comment #7:

can we make this a user preference, pls?
in my (slow) computer, the overhead seems waay more than 20%.

Felipe G. Nievinski <fgnievinski>
Mon 20 Jan 2014 02:12:20 PM UTC, comment #6:

The workspace view still refreshes to show variables while scripts are running, if that's what you mean.

Mike Miller <mtmiller>
Project Member
Mon 20 Jan 2014 05:55:43 AM UTC, comment #5:

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?

Dan Sebald <sebald>
Mon 20 Jan 2014 03:38:54 AM UTC, comment #4:

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.

Mike Miller <mtmiller>
Project Member
Thu 08 Aug 2013 07:36:41 PM UTC, comment #3:

Here is a test from my system (not the newest one):

Despite of the general overhead of the GUI the activities in the workspace really slow down the calculation.

Torsten <ttl>
Project Member
Mon 05 Aug 2013 03:49:16 PM UTC, comment #2:

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.

Dan Sebald <sebald>
Mon 05 Aug 2013 01:55:15 PM UTC, comment #1:

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.

I ran the following sequence:

In Octave with the GUI:
Elapsed time is 42.2558 seconds.

Command-line Octave:
Elapsed time is 42.0342 seconds.

Mike Miller <mtmiller>
Project Member
Thu 01 Aug 2013 05:53:37 PM UTC, original submission:

I noticed a flash of contents of the variable space inside fftfilt when doing

test fftfilt

that goes away once the tests are done. This really slows down the operation of "test fftfilt".

I've attached a PNG image of what the workspace looks like momentarily by running the test 100 times then capture the screen at the right moment.

Dan Sebald <sebald>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by fgnievinski (Posted a comment)
  • -unavailable- added by ttl (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by sebald (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 06 Feb 2014 02:18:56 PM UTCmtmillerDependencies-=>bugs #41467 is dependent
    Mon 20 Jan 2014 03:38:54 AM UTCmtmillerSeverity3 - Normal=>2 - Minor
      StatusWorks For Me=>Confirmed
    Mon 05 Aug 2013 01:55:15 PM UTCmtmillerItem GroupNone=>Performance
      StatusNone=>Works For Me
    Thu 01 Aug 2013 05:53:37 PM UTCsebaldAttached File-=>Added Screenshot-Octave-workspace_overload.png, #28737

    Back to the top


    Powered by Savane 3.1-cleanup