Re: QtHandles and performance

[Rik]

On 01/09/2014 12:06 PM, address@hidden wrote:
> Message: 8
> Date: Thu, 9 Jan 2014 15:06:25 -0500
> From: Michael Goffioul <address@hidden>
> To: "John W. Eaton" <address@hidden>
> Cc: octave maintainers mailing list <address@hidden>
> Subject: Re: integrating QtHandles with Octave
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Jan 9, 2014 at 2:34 PM, John W. Eaton <address@hidden> wrote:
>
>> > I'm working on integrating QtHandles with Octave.  When I have
>> > something ready, I'll be pushing my changes on the gui-release branch.
>> > So far, I have done enough to make it compile and show plots but I've
>> > noticed some problems.
>> >
>> > First, doing "rundemos draw" (previously "rundemos plot", but
>> > top-level plotting functions have been moved to the plot/draw
>> > subdirectory) hangs on a number of demos including all those for ez*
>> > plot functions and a few others.  I haven't investigated too much, but
>> > the common thing seems to be the use of function handles.  I also
>> > haven't tried building the QtHandles package for an older version of
>> > Octave.  I can do that, but maybe someone who has that already set up
>> > can just tell me whether the demos for the ez* plot functions work
>> > properly with the QtHandles package and Octave 3.6.4.
>> >
>> > Second, I noticed some random crashes.  I guessed that this might be
>> > due to not using --enable-atomic-refcount, so I rebuilt with that
>> > configure option and haven't noticed a crash since.  However, I have
>> > not done extensive testing.  I think Michael said that this is
>> > required for QtHandles.  If so, then we have some decisions to make
>> > because as I recall using the atomic reference counting option had a
>> > significant (about 10%) impact on performance.  If we enable it by
>> > default, it will slow all Octave operations.  If we want to enable it
>> > for the GUI only, then we will have to build a completely separate set
>> > of libraries for octave-cli.
>> >
>> > I remember that we discussed this topic previously, but I don't think
>> > we ever came to a conclusion.
>> >
> Atomic ref-counting is required for QtHandles, as the GUI runs in a
> separate thread and accesses graphics objects from there. There is indeed a
> performance penalty, which is more visible when creating/deleting a lot of
> objects; it doesn't impact pure math routines, like BLAS or LAPACK. No
> decision was made at the time, as it was believed the performance penalty
> was too high.
>
> Michael.
> ------------

Do we need to re-measure the performance penalty before we can make an
informed decision, or are we confident in the 10% number?

If the performance penalty is only associated with displaying graphics
objects, and not pure math functions, then is this pretty much acceptable? 
Graphics are measured on a human time scale, hundreds of milliseconds to
actual seconds, rather than the microseconds of inner loops so there is
abundant headroom for some slowdown.

--Rik