Thanks Ken,
I was afraid to get an answer like this:-)
Am 01.02.2011 um 02:07 schrieb Ken Thomases:
On Jan 31, 2011, at 5:13 PM, Peter Lübke wrote:
I use a worker thread in my app that invokes the same method(s) on
all objects in an array sent from the main thread. The array may
contain thousands of objects.
The main thread communicates with the worker thread via
distributed objects.
Everything works fine except performance is too slow.
Seems to me that my NSConnection asks for the method signature
each time the method is invoked on an object in the array, thus
adding massive overhead.
Well, that's part of it, but probably not the biggest part.
The way you're using D.O. defeats the purpose of having a worker
thread.
Sending the array from the main thread to the worker thread causes
the worker thread to receive a proxy for the array. Then, as you
request each element of the array, that's a message to the main
thread and back, and what you get is... a proxy for the element
(not the element itself). Then, every operation you perform on the
element is a message to the main thread _and the main thread
performs the work on behalf of its "client"_.
So, you have effectively failed to shift the work from the main
thread to the worker thread. The main thread is a "server" doing
all of the work on the behalf of its client, the worker thread.
Not quite... In this case, the worker thread is the server.
I guess that's why the main thread is all the way responsive. The
worker thread also sends messages to the main thread updating a
progress indicator which all works nice.
If you're going to use D.O., ideally you want the messages to
either carry no data or to carry data values (bycopy), not
references to objects.
Thanks for clarifying this. This explains a point I totally overlooked.
Also, you want to design a fairly coarse-grained protocol of
requests that a client can make of the server -- few requests to do
some big chunks of work, not many requests for small chunks of work.
This is what I thought I was doing, the "bad" thing - if I get it
right - is that I pass the array to the server?
The shared objects approach - call NSThread's -
detachNewThreadSelector:toTarget:withObject: with the array as
argument 3, have the secondary thread do the job and exit - is way
faster!
Is there a reason that's not sufficient? Why are you trying to use
D.O.?
There's a bunch of these arrays around, all containing objects of one
class. There's another bunch of objects of various classes that
access these objects.
I didn't like the idea of implementing the creation of threads that
always kind of do the same sort of work in each of these different
classes.
So I thought it might be a good idea to have a singleton "thread
manager" create worker threads as needed and coordinate those
different object's requests.
Reading your statements, I will have to spent some thoughts on the
basic concept...
Thanks,
Peter
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
