On Wednesday 16 April 2014 14:46:56 Branislav Katreniak wrote:
As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
measured the difference between the current approach and using atomics
using Olivier's initial benchmark, it's about 4-5x slower for checking if
there's
On Wednesday 16 April 2014 12:55:38 Matthew Woehlke wrote:
On 2014-04-16 03:18, Volker Krause wrote:
On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
In other words: use QBasicAtomicPointer.
As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
measured the
On Thursday 17 April 2014 18:11:03 Kevin Funk wrote:
On Wednesday 16 April 2014 12:55:38 Matthew Woehlke wrote:
On 2014-04-16 03:18, Volker Krause wrote:
On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
In other words: use QBasicAtomicPointer.
As mentioned on
Em ter 22 abr 2014, às 21:02:24, Milian Wolff escreveu:
BTW: Did you really compile this with Qt5? The operator T*() is gone from
QAtomicPointer, no?
https://qt-project.org/doc/qt-5/qatomicpointer-members.html
It's back.
On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
Em ter 15 abr 2014, às 09:49:53, Matthew Woehlke escreveu:
If you add the rule that callbacks can't be removed once registered, you
could do an atomic exchange of the old callback for the new, and require
that any attached callback
As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
measured the difference between the current approach and using atomics using
Olivier's initial benchmark, it's about 4-5x slower for checking if there's a
callback set. Since this is affecting every Qt application on a
On 2014-04-16 03:18, Volker Krause wrote:
On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
In other words: use QBasicAtomicPointer.
As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
measured the difference between the current approach and using atomics using
On 2014-04-09 03:24, Volker Krause wrote:
- thread-safety: we might be setting the callback at a point where already
several threads are active. For us it's less relevant that we don't miss a few
calls from other threads there (attaching at runtime happens at an arbitrary
point in time
Em ter 15 abr 2014, às 09:49:53, Matthew Woehlke escreveu:
If you add the rule that callbacks can't be removed once registered, you
could do an atomic exchange of the old callback for the new, and require
that any attached callback calls the previously-registered callback
also. (This would
On Tuesday 08 April 2014 23:53:11 André Pönitz wrote:
On Tue, Apr 08, 2014 at 11:00:18PM +0200, Olivier Goffart wrote:
On Tuesday 08 April 2014 07:42:46 Thiago Macieira wrote:
Em ter 08 abr 2014, às 15:49:16, Volker Krause escreveu:
API-wise we are quite flexible (can't get any more
On Monday 07 April 2014 10:18:40 Thiago Macieira wrote:
Em seg 07 abr 2014, às 17:48:46, Volker Krause escreveu:
The current situation is that the hooks work fine on Linux/QNX in
combination with LD_PRELOAD (unless you have a non-recent gold that
ignores
QtCore.dynlist). They also work
volker.kra...@kdab.com:
So unless there's some compiler magic I missed I think this needs a
different approach to be reliable and cross-platform, such as callbacks.
Would this be acceptable? If so, would a minimal approach similar to
qt_register_signal_spy_callbacks() or rather
Em ter 08 abr 2014, às 15:49:16, Volker Krause escreveu:
API-wise we are quite flexible (can't get any more dirty than what we do now
;) ), I was mainly asking due to this being on a performance-relevant path.
The QInternal callback system is obviously more flexible (and thus would be
my
On Tuesday 08 April 2014 07:42:46 Thiago Macieira wrote:
Em ter 08 abr 2014, às 15:49:16, Volker Krause escreveu:
API-wise we are quite flexible (can't get any more dirty than what we do
now ;) ), I was mainly asking due to this being on a performance-relevant
path. The QInternal callback
On Tue, Apr 08, 2014 at 11:00:18PM +0200, Olivier Goffart wrote:
On Tuesday 08 April 2014 07:42:46 Thiago Macieira wrote:
Em ter 08 abr 2014, às 15:49:16, Volker Krause escreveu:
API-wise we are quite flexible (can't get any more dirty than what we do
now ;) ), I was mainly asking due to
Em ter 08 abr 2014, às 23:00:18, Olivier Goffart escreveu:
Performance-wise, I'd prefer empty functions that get overridden at
runtime. That's the smallest overhead for when they are not present.
According to a quick benchmark (attached), it is clearly more efficient to
have:
if
Hi,
I'm looking into making the qt_add/removeObject(QObject*) hooks useful on
more platforms. Having those available considerably improves the results you
get in GammaRay, compared to the fallback mode that tries to find objects via
global event filters and hierarchies.
The current situation
Em seg 07 abr 2014, às 17:48:46, Volker Krause escreveu:
The current situation is that the hooks work fine on Linux/QNX in
combination with LD_PRELOAD (unless you have a non-recent gold that
ignores
QtCore.dynlist). They also work on Mac/Windows, with the nasty function re-
writing code we
18 matches
Mail list logo
