Re: GUI release

[Daniel J Sebald]

On 01/27/2015 08:20 PM, Rik wrote:
> On 01/27/2015 04:35 PM, address@hidden wrote:
> > Subject:
> > Re: Release Ideas
> > From:
> > "John W. Eaton" <address@hidden>
> > Date:
> > 01/27/2015 04:35 PM
> >
> > To:
> > Michael Godfrey <address@hidden>, address@hidden
> >
> > List-Post:
> > <mailto:address@hidden>
> > Content-Transfer-Encoding:
> > 7bit
> > Precedence:
> > list
> > MIME-Version:
> > 1.0
> > References:
> > <address@hidden> <address@hidden>
> > In-Reply-To:
> > <address@hidden>
> > Message-ID:
> > <address@hidden>
> > Content-Type:
> > text/plain; charset=utf-8; format=flowed
> > Message:
> > 7
> >
> >
> > On 01/27/2015 06:40 PM, Michael Godfrey wrote:
> >
> > > Unless there is something blocking default, why not just make one
> > > release (default already has all the
> > > GUI code).
> >
> > We deprecated some things in 3.8 that have already been removed from
> > default but not gui-release.  Normally we have one release that still
> > contains the deprecated functions but warns if they are used.
> > Skipping the gui-release release and going straight to default would
> > break this promise that we normally make.  Not a huge thing, I
> > suppose, but something we should consider if we decide to just release
> > default.
> >
> > jwe
>
> I don't think we want to wait much longer for a GUI release.  The
> development branch continues to make great strides, but it is rapidly
> diverging from the gui-release branch.  I would prefer to see us keep
> the promise about maintaining deprecated code for two releases.
>
> In terms of what to do, there is a checklist of activities for a release
> on the wiki at http://wiki.octave.org/Roadmap.  One of the first
> priorities is figuring out which bugs require fixing before the release
> and which would only be nice to fix.  In the past we have tried to fix
> all segmentation faults, all regressions, and any bugs with a severity >
> 4.  A quick search on Savannah shows that there are 38 bugs marked as
> crashes.  One thing that becomes apparent is that the GUI has a lot of
> trouble running and plotting under Mac OS X.  Certainly we will need to
> have some sort of solution for that OS.
>
> My main concern is the slow down in performance in Octave under the
> GUI.  As a quick gauge I tried runtests on the corefcn directory.  See
> below.
>
> --Benchmark Code--
> more off
> t0 = cputime(); runtests ("libinterp/corefcn"); t1 = cputime(); t1 - t0
> --End Code--
>
> hg: 101ce4eaa56c (gui-release)
>
> GUI:
> ./run-octave -f
> time : 145.40
>
> CLI:
> ./run-octave -f --no-gui-libs
> time : 80.489
>
> Built with --disable-atomic-refcounts
>
> GUI:
> ./run-octave -f
> time : 126.40
>
> CLI:
> ./run-octave -f --no-gui-libs
> time : 71.136
>
> There is about an 80% decrease in performance when running the GUI.  It
> seems like maybe the update frequency for items in the Variable Browser
> pane could be slower when Octave is fully engaged making a calculation.
>
> --Rik


Here's what I'm seeing (but I may not being running the same exact 
version/branch you are):

GUI:
./run-octave -f
ans =  45.351

CLI:
./run-octave -f --no-gui-libs
ans =  27.983

So 60% here.  However, in my case it's clear the big difference is the 
display.  One of these tests is displaying a huge matrix and during that 
time I don't see any update of the state variables.  Where the console 
command line zips through the display of the large matrix in a matter of 
a few seconds, the same matrix displayed in the GUI seems to take tens 
of seconds.  It could be that the Qt display window has more lines in 
its memory, or is simply less efficient at updating the display because 
of Qt framework overhead.

It seems to me there are two significant time drains: the GUI display 
and the atomic reference counts (per your data).  And then perhaps there 
is a bit for something else--perhaps the workspace variable update...but 
I don't see anything happening in the workspace during the following 
computation:

GUI:
> > t0=cputime(); x=1; for i=1:1000000; x = sqrt(x+1); end; t1=cputime(); t1-t0
ans =  9.5256
> > t0=cputime(); x=1; for i=1:1000000; x = sqrt(x+1); end; t1=cputime(); t1-t0
ans =  9.4986

CLI:
octave:1> t0=cputime(); x=1; for i=1:1000000; x = sqrt(x+1); end; 
t1=cputime(); t1-t0
ans =  8.1318
octave:2> t0=cputime(); x=1; for i=1:1000000; x = sqrt(x+1); end; 
t1=cputime(); t1-t0
ans =  8.7867

Dan