Re: Performance hit with --enable-atomic-refcount

[Michael Goffioul]

On Mon, Jun 9, 2014 at 1:34 PM, Daniel J Sebald <address@hidden> wrote:

On 06/09/2014 11:04 AM, Michael Goffioul wrote:

On Mon, Jun 9, 2014 at 11:38 AM, Daniel J Sebald <address@hidden

<mailto:address@hidden>> wrote:

    On 06/06/2014 12:40 PM, Rik wrote:

        6/6/14

        All,

            >From the previous benchmarking, there was a doubling in execution time from

        3.8.1 to the gui-release branch for a nested for loop.  It turns
        out that
        this doubling is 100% correlated with using the
        --enable-atomic-refcount
        option to configure.  I built the gui-release branch with this
        feature
        disabled and the results are then equivalent to the 3.8.1
        release.  It
        seems like we need to explore a different solution than this
        configure
        option so that we can both use Qt graphics and have reasonable
        performance.


    The attomic reference count is, from what I understand, needed for
    the QtHandles code, which implements script callbacks (I say "script
    callbacks" to differentiate from source code callbacks).  Atomic
    reference isn't needed for Qt graphics without that.


No, atomic reference is a way to implement seamless concurrent access to
octave_value objects (and other ref-counted objects), between the UI
event loop and the octave thread.

Sure.  The question is, Why should the GUI have free access to octave_value objects in the worker process?

To plot them.

Michael.