Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>are we supposed to name that Xamarin.iOS now?</p> </blockquote> <p>Yes, it's Xamarin.iOS now :-)</p> <blockquote> <p>Or is this a tax to pay when P/Invoking in MT ?</p> </blockquote> <p>There's a lot of things do be done while transitioning from managed and unmanaged code. The trampolines take cares of this: marshaling parameters and return values, handling managed exception, handling native exception...</p> <p>Also you might be doing the transition many times, e.g. <code>new Managed ();</code> calls native <code>init*</code> which calls (native) <code>setFoo:</code> which goes back to (managed) <code>Foo</code> setter (and back... to callers).</p> <p>So even if each part is fast it can still be notable if you do a no-op (or just call <code>base</code>) since there's no much <em>user time</em> to amortize against.</p> <blockquote> <p>Is there a way to speed that up, from one side or the other (native or managed) ?</p> </blockquote> <p>Yes. First make sure you measure the <em>real</em> thing. E.g. </p> <ul> <li><p>The above tasks differs from the simulator and devices, e.g. JIT versus AOT, different ABI for x86 and ARM;</p></li> <li><p>Debug and release build configuration will also use different code;</p></li> </ul> <p>So you likely want to measure a Release build on an iOS (ARM) device.</p> <p>The next thing you should do is to ensure <strong>Link all assemblies</strong> is enabled (if you have non-SDK bindings, e.g. Cocos2d). That won't change the trampolines but when you call <code>base</code> you're calling binding code. </p> <p>And it turns out that the linker is <em>very smart</em> about bindings and can remove code that is not required in your situation. E.g.</p> <ul> <li><a href="http://spouliot.wordpress.com/2012/05/07/linker-vs-bindings-and-isdirectbinding/" rel="nofollow">remove checks and branches related to <code>IsDirectBinding</code></a>;</li> <li><a href="http://spouliot.wordpress.com/2012/03/05/linker-vs-bindings-and-newrefcount/" rel="nofollow">remove code related to <code>NewRefCount</code> (sgen option)</a>;</li> <li><a href="http://spouliot.wordpress.com/2012/02/29/linker-vs-bindings-and-runtime-arch/" rel="nofollow">remove checks and branches related to 'Runtime.Arch`</a>;</li> <li><a href="http://spouliot.wordpress.com/2012/02/29/linker-vs-bindings-and-runtime-arch/" rel="nofollow">remove checks for UI thread checks</a> (in case you inherit from UIKit); and</li> <li>any future optimization we add in the future :-)</li> </ul> <p><strong>EDIT</strong>: another reason to enable the linker is that it remove the extra (unused) methods in the bindings - making it less likely that the native code needs to call back into the managed world (and less transitions means faster times)</p> <p>Other ways are more invasive and might require code changes to minimize the chatter between managed and native code. E.g. sometime you can call</p> <pre><code>var x = new X (1, 2, 3, 4); </code></pre> <p>or</p> <pre><code>var x = new X (); x.a = 1; x.b = 2; x.c = 3; x.d = 4; </code></pre> <p>You can guess the first case would require less transitions (and be faster). If such API does not exists then it <em>could</em> be added - but that should be a least resort option (there's likely other places where optimization would get you a larger pay off).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload