On Mon, Jun 9, 2014 at 1:34 PM, Daniel J Sebald <address@hidden
<mailto: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>
<mailto: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.