NSConnection recursion -- (was Re: Long term performance of NSConnection)
Kirk Kerekes wrote: Use Activity Monitor (or other tool of your choice) to check for a port leak. It wasn't that... Turns out that the protocol on the connection had a call which took an Objective C object as a parameter. The parameter wasn't declared as /byref/ or /bycopy/, so I believe it defaulted to /byref/. In the remote function, that object was being sent a message, which appeared to call back into the original process. There was only one part of the object that was being used, an integer, so I changed the API to pass the integer value instead of the object, and the performance problems went away. Possibly declaring it as /bycopy/ would have done the same thing, but there was no point in copying the entire object when we only needed one piece of it. It's not completely clear why the performance hit was cumulative. I suspect that the call back to the original process was creating connections on the fly and not cleaning them up. If that's the case I think it's a bug in the NSDistantObject code. Kevin ___ 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
Re: Long term performance of NSConnection
Are you sure you are not instantiating/creating/opening a connection each time? are you really reusing the same connection? Aurélien, Objective Decision Team On 2 juil. 09, at 21:29, Kevin Brock wrote: We've got an application that uses some NSConnection objects to call between binaries. An application calls interfaces of an object which is vended by a daemon. The calls between modules are made frequently, and during some testing I noticed a steady drop in perfomance of the application. I ran Shark, and saw that after a lot ( 1,000,000) calls across the API more than 95% of the time was being spent in 5 calls, all of which look like they're related to distributed objects: lookUpConnectionForProxy 30.5% lookUpLocalProxyForWireID 26.5% lookUpLocalObjectForProxy 22.8 lookUpOrCreateLocalProxyForObject 8.2% lookUpWireIDForProxy 7.6% I can't find any references to these functions on the net, and don't see anything in the docs that would explain this. We use a long term, persistent connection. The degradation starts very soon. Call Startup ~10,000 calls ~20,000 Calls lookUpConnectionForProxy0.4% 4.2% 14.6% lookUpLocalProxyForWireID 0.8% 12.4% 15.7% lookUpLocalObjectForProxy 0.3% 2.8% 8.8% lookUpOrCreateLocalProxyForObject 0.5% 3.3% 4.8% lookUpWireIDForProxy0.1% 0.7% 3.3% Is there something we are missing about the usage of the connection object? It looks like there's some table internal to the connection that's not being cleaned up. When I graph the actual perormance hit taken by the application (secs/1000 connections) it's essentially linear increase in time from 0 to 500,000 connections. When I run Shark on the daemon side for the 1,000,000 call case it shows three calls consuming 97% of the time Call Time lookUpConnectionForProxy58% lookUpWireIDForProxy28.9% lookUpOrCreateLocalProxyForObject 11.2% I'd really appreciate any suggestions about why this might be happening. Kevin Brock ap...@kevin.com ___ 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/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ 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
Re: Long term performance of NSConnection
Aurélien Hugelé wrote: Are you sure you are not instantiating/creating/opening a connection each time? are you really reusing the same connection? Yes. There's a lot of logging around that code. If it was being closed and re-opened we'd see it. I've also debugged through that code, and the initialization routines are only called once. In the event of closing and re-opening the connection each time I'd expect to see a constant performance hit, not one that increased over time. Kevin Aurélien, Objective Decision Team On 2 juil. 09, at 21:29, Kevin Brock wrote: We've got an application that uses some NSConnection objects to call between binaries. An application calls interfaces of an object which is vended by a daemon. The calls between modules are made frequently, and during some testing I noticed a steady drop in perfomance of the application. I ran Shark, and saw that after a lot ( 1,000,000) calls across the API more than 95% of the time was being spent in 5 calls, all of which look like they're related to distributed objects: lookUpConnectionForProxy 30.5% lookUpLocalProxyForWireID 26.5% lookUpLocalObjectForProxy 22.8 lookUpOrCreateLocalProxyForObject 8.2% lookUpWireIDForProxy 7.6% I can't find any references to these functions on the net, and don't see anything in the docs that would explain this. We use a long term, persistent connection. The degradation starts very soon. Call Startup ~10,000 calls ~20,000 Calls lookUpConnectionForProxy 0.4% 4.2% 14.6% lookUpLocalProxyForWireID 0.8% 12.4% 15.7% lookUpLocalObjectForProxy 0.3% 2.8% 8.8% lookUpOrCreateLocalProxyForObject 0.5% 3.3% 4.8% lookUpWireIDForProxy 0.1% 0.7% 3.3% Is there something we are missing about the usage of the connection object? It looks like there's some table internal to the connection that's not being cleaned up. When I graph the actual perormance hit taken by the application (secs/1000 connections) it's essentially linear increase in time from 0 to 500,000 connections. When I run Shark on the daemon side for the 1,000,000 call case it shows three calls consuming 97% of the time Call Time lookUpConnectionForProxy 58% lookUpWireIDForProxy 28.9% lookUpOrCreateLocalProxyForObject 11.2% I'd really appreciate any suggestions about why this might be happening. Kevin Brock ap...@kevin.com ___ 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/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ 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
Re: Long term performance of NSConnection
Use Activity Monitor (or other tool of your choice) to check for a port leak. ___ 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
Long term performance of NSConnection
We've got an application that uses some NSConnection objects to call between binaries. An application calls interfaces of an object which is vended by a daemon. The calls between modules are made frequently, and during some testing I noticed a steady drop in perfomance of the application. I ran Shark, and saw that after a lot ( 1,000,000) calls across the API more than 95% of the time was being spent in 5 calls, all of which look like they're related to distributed objects: lookUpConnectionForProxy 30.5% lookUpLocalProxyForWireID 26.5% lookUpLocalObjectForProxy 22.8 lookUpOrCreateLocalProxyForObject 8.2% lookUpWireIDForProxy 7.6% I can't find any references to these functions on the net, and don't see anything in the docs that would explain this. We use a long term, persistent connection. The degradation starts very soon. Call Startup ~10,000 calls ~20,000 Calls lookUpConnectionForProxy0.4% 4.2% 14.6% lookUpLocalProxyForWireID 0.8% 12.4% 15.7% lookUpLocalObjectForProxy 0.3% 2.8% 8.8% lookUpOrCreateLocalProxyForObject 0.5% 3.3% 4.8% lookUpWireIDForProxy0.1% 0.7% 3.3% Is there something we are missing about the usage of the connection object? It looks like there's some table internal to the connection that's not being cleaned up. When I graph the actual perormance hit taken by the application (secs/1000 connections) it's essentially linear increase in time from 0 to 500,000 connections. When I run Shark on the daemon side for the 1,000,000 call case it shows three calls consuming 97% of the time Call Time lookUpConnectionForProxy58% lookUpWireIDForProxy28.9% lookUpOrCreateLocalProxyForObject 11.2% I'd really appreciate any suggestions about why this might be happening. Kevin Brock ap...@kevin.com ___ 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
