Performance

= Details =

The three different methods for calling into Objective-C from Javascript have some significant performance implications.

== Underlying Mechanisms ==

Native Obj-C bridge:

• Uses standard WebKit methods which are not yet documented/exposed in the iPhone 2.1 OS SDK
• Relies upon the native WebKit Objective-C / Javascript bridging capabilities
• (Presumably) allows reference counting between language domains, which is a huge win
• Can translate simple data types (NSString, NSNumber) and wraps others in WebScriptObject
• Allows synchronous and asynchronous operation

UIWebView URL loading hook:

• Relies only upon documented and iPhone-kosher UIWebView delegate and UIWebView methods
• Semantics of setting window.location are unclear, but no return value comes from a set of window.location
• Only allows data types which can be expressed as JSON (or other string form)
• Allows only asynchronous operation.

XMLHTTPRequest / Ajax:

• Relies upon documented and iPhone-kosher networking APIs
• Has a relatively large code footprint due to embedded HTTP server
• High latency, but better handling of large or binary data sets
• Only allows data types which can be expressed as JSON (or other string form)
• Could theoretically be used for distributed RPC between iPhones
• Allows both synchronous and asynchronous operation

== Benchmarking Invocation Methods ==

All tests were performed with NSLog nullified to reduce overhead.

There’s a much steeper performance curve on the Simulator than on actual hardware. However, it looks like at least a 4-5x overhead increase from the fastest method to the Ajax / XMLHTTPRequest method used by Nitrox.

= Performance on first-gen iPhone Hardware, OS 2.1 =

	Method		Time
	native Obj-C bridge		10.26 ms
	URL loading hook		16.92 ms
	XMLHTTPRequest / Ajax		65.18 ms

== Performance on Macbook Pro, Simulator, OS 2.1 ==

	Method		Time
	native Obj-C bridge		0.04 ms
	URL loading hook		0.54 ms
	XMLHTTPRequest / Ajax		2.16 ms