Threads & communication performance
Threads & communication performance
- Subject: Threads & communication performance
- From: Laurent Michel <email@hidden>
- Date: Mon, 8 Aug 2005 18:16:57 -0400
Hello everyone,
I have a behavior in my application that is somewhat disappointing
and puzzling. In a nutshell, the application has two threads, one is
a Cocoa thread and manages the UI, the other is compute-bound. The
compute bound thread wishes to send 'updates' to the UI thread
regularly (when events of interest occurs). For all practical
purpose, imagine that I wish to draw/refresh a matrix (so the UI will
use an NSMatrix) and each cell will hold a value and a color that
depends on the sign of the value.
I have implemented this in two ways:
- via performSelectorOnMainThread: to delegate back to the UI thread
the task of 'updating' a matrix cell (text & color) whenever it
changes on the other side. For waitUntilDone: I pass TRUE (so this is
synchronous).
- via NSConnection, ports and proxying. Same deal here, but
'different' technology. The real object is on the UI side and the
request are made on the proxy that 'channels' them back to the main
thread since the NSConnection is serviced in that main runLoop.
I also have A Gtk based implementation of all this stuff. Under X11,
a pipe is used to channel the method invocation back to the main
thread. In all three cases, the implementation work as expected
*from a functionality point of view*.
What I observed (on a dual G5)
- Gtk implementation: Both CPUs are almost maxed out. Performance
seem ok, could be a little a better (or so I thought).
- Cocoa + performSelectorOnMainThread: Both CPU are mostly idle!
anywhere around 10%. Performance is somewhat below the Gtk version.
- Cocoa + NSConnection: Same as above. no performance improvement
whatsoever.
To give some more data:
The compute thread alone (no UI): 3 seconds to complete
The compute thread with the UI (as reported by time on the command line)
- WALL CLOCK:1 minute 6 seconds.
- USERTIME=11.6 seconds
- SYSTEMTIME = 2.2 seconds
It almost sounds like sleep or nanosleep is called somewhere in the
code!
So... the fact the the CPU seems to idle on Cocoa, I would hope for
better performance than Gtk, yet the current setup does not deliver.
What am I missing ? What did I do wrong ? What should I do to speed
this up and channel the request back to the main thread faster ?
Since the compute thread is compute-bound, it should saturate the UI
thread with request to refresh, yet, it does not happen, I experience
high wall-clock time and low user/system time...
Any suggestion is most welcomed.
Final note: I just added one more test: performSelectorOnMainThread
with waitUntilDone: set to FALSE. The gain is quasi inexistent and
probably negated by the memory allocation that must take place to
pack and save the arguments.
Thanks a lot.
---
Laurent
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden