
Apple's FTLJIT project aims to give JavaScript a boost - mmastrac
http://www.infoworld.com/t/javascript/apple-has-its-own-javascript-accelerator-in-the-works-242042 
======
peterhunt
I have built lots and lots of stuff on mobile web. Never once was JavaScript
perf the bottleneck on iOS. Never (especially since the rise of retina
screens).

I think there is a lot of hyperbole around the whole JIT in webview thing from
people who don't have a good grasp of where the performance problems are on
mobile web.

~~~
etrinh
This. To my knowledge, JS perf isn't an issue in any modern browser (even the
crippled iOS webview). Improving the performance of DOM access and
manipulation (not just on iOS) would be a much more fruitful enterprise and is
something I would like to see all browser makers focusing on.

~~~
malandrew
A million times this. XML at the end of the day is a language with only two
types, strings and children. This is woefully inadequate if you want
performance.

Take a 3D matrix transform for example. It needs to be marshalled from an
array of floats to a string to be applied. Then it needs to be parsed back
into an array of floats to be used to position a texture in the GPU. Such a
huge waste...

------
untog
Hopefully they'll allow it to be used inside app WebViews. Nitro is already
great, but it's disabled inside apps.

~~~
eridius
The only way any JIT at all will ever be allowed inside of UIWebViews is when
UIWebView makes the jump to WebKit2, i.e. using a helper process to actually
run the web content.

~~~
dunham
They might be able to handle it with a remote view controller. An existing iOS
technology that allows for a view controller that fronts an out-of-process
application. This is used for the mail composer and facebook sharing.

See: [http://oleb.net/blog/2012/10/remote-view-controllers-in-
ios-...](http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/)

(I suspect there are some constraints on how a remote view controller can be
used, and they'd have to do some additional work to shunt in NSURLProtocol and
all.)

~~~
eridius
That's quite unrelated. That's a technology that allows for e.g. the Mail
compose screen to run out-of-process while still compositing into the same
layer hierarchy as the host application and receiving touches. This not only
allows restricting access to Mail accounts to the daemon that runs the remote
controller, but also prevents the host application from doing things like
hiding the mail compose controller behind another view and forwarding touches
to it, so a press on an unrelated button actually triggers an email send.

WebKit2 is done differently. The UIWebView still handles all the user
interaction and whatnot, and it talks to the Web Process to send it requests
(e.g. "load this URL", "run this JavaScript in the context of the page", etc).
I'm not quite sure how the compositing of the web content works, but it's not
the same system as remote view controllers.

~~~
0x0
There's stuff here about a UIRemoteWebViewController:

[http://oleb.net/blog/2012/10/more-on-remote-view-
controllers...](http://oleb.net/blog/2012/10/more-on-remote-view-controllers/)

[https://github.com/nst/iOS-Runtime-
Headers/blob/master/Frame...](https://github.com/nst/iOS-Runtime-
Headers/blob/master/Frameworks/UIKit.framework/_UIRemoteWebViewController.h)
[https://github.com/nst/iOS-Runtime-
Headers/blob/master/Frame...](https://github.com/nst/iOS-Runtime-
Headers/blob/master/Frameworks/UIKit.framework/_UIServiceWebViewController.h)

~~~
eridius
Possibly interesting information, but still not actually relevant to WebKit2.

~~~
dunham
I might not have been clear in my grandparent post. I wasn't proposing this as
a means to WebKit2. (I don't know what WebKit2 is.) I was suggesting this
might be a way to get JIT support in native apps with the current iOS WebKit,
by running the entire UIWebKit out of process.

However, I have no idea if there are enough hybrid apps out there, with
javascript performance issues, to justify going to the trouble of doing this.

~~~
eridius
Ah. Well, it's a cute idea, but it won't work with UIWebView. Besides the fact
that existing apps already rely on the fact that UIWebView isn't remote
(because they can muck about with various view properties of it, including
direct access to its UIScrollView), UIWebView also exposes at least one
synchronous API (-stringByEvaluatingJavaScriptFromString:) and synchronous
APIs are no good when doing stuff out-of-process. It also has a delegate that
runs in a synchronous mode (e.g. it's asked questions it has to answer by
returning a value, instead of just being notified of events or using a
callback-based response), and that's the same problem as synchronous APIs
(because now the remote process has to block waiting on a response from
UIWebView).

WebKit2 is an existing effort by Apple to do out-of-process rendering. Various
desktop apps already use it, including Safari, Mail, and iBooks. It features
new APIs for doing everything, because it's all asynchronous. If third-party
iOS apps gain out-of-process rendering it will be through WebKit2 and not some
attempt to port UIWebView to the remote view controller system.

Incidentally, the same synchronous issues with UIWebView that I mentioned
above suggest that porting to WebKit2 is a non-backwards-compatible change. If
Apple makes this change, I would guess that either they'll introduce a
separate UIWebView class that's used for WebKit2 and leave the existing
UIWebView alone, or they'll give UIWebView two modes, a WebKit mode and a
WebKit2 mode, and whichever mode it uses will be selected at initialization
time (and using a WebKit method on a WebKit2 UIWebView would be an error, and
vice versa). Either way, apps will have to be rewritten to take advantage of
WebKit2.

~~~
0x0
What is it that makes a synchronous call to an out of process view on ios so
bad?

Also, apple has changed the internal subviews of system views before. In some
cases they seem to provide a backwards compatible subview layout mode
triggered by looking at the compiler/linker/sdk version so existing binaries
will keep running. For sure I have seen previously working code like this
breaking merely by recompiling with a newer xcode, as if it is taken to be an
opt-in to new internal layouts - but not always; sometimes even existing apps
needs rush updates if they have been assuming too much about undocumented
subview hierarchies.

~~~
eridius
> What is it that makes a synchronous call to an out of process view on ios so
> bad?

Because it's blocking the main thread. Worse, it's blocking the main thread
doing something that has effectively no upper bound on how long it can take.
Web Process is blocked trying to handle a previous request to calculate Pi to
a trillion digits in javascript? Oops, your synchronous call to execute more
javascript will just have to wait. Indefinitely.

> Also, apple has changed the internal subviews of system views before.

I'm not talking about internals. UIWebView directly exposes its scrollView as
public API. And you can muck with the view properties of the UIWebView too to
make changes. For example, if you really want to you could set your UIWebView
to 50% alpha (and this is totally legit, not depending on internal subview
hierarchies). Whereas Remote View Controllers explicitly prevent you from
mucking with any aspect of the view hierarchy.

~~~
0x0
It would still be blocking the main thread if it was in-process? I'm not
seeing the big deal here, at least if there's a 1:1 relationship of web views
and the out of process counterparts. And it's not like ios is running a lot of
foreground apps simultaneously either.

Fair enough about the scrollviews, although maybe they could be proxied
somehow.

~~~
eridius
I suppose you're right in that my example of calculating pi only makes sense
if you're sharing the web process with another app. But the real point, that I
skipped to try and make what I thought was the more dramatic (but flawed)
point, is that out-of-process requests have built-in latency that in-process
requests don't. It's just plain bad design to have a synchronous API that
talks to another process.

------
ahomescu1
The title makes me cringe. It makes it sound like this is the first JIT from
Apple, when it's actually the "Fourth Tier LLVM" JIT. It goes on top of the
current JavaScript engine, which is already pretty fast.

~~~
dang
Ok, we replaced it with the subtitle.

------
batmansbelt
Safari is basically the worst browser right now. They have a firm toe hold in
mobile obviously, but in terms of desktop it's the worst browser to support,
even behind IE. Nice to see them finally getting with the times. Every other
browser has had this technology for years.

~~~
matthewmacleod
This is just flat wrong. Safari is basically at feature parity with Chrome,
which isn't surprising given that they only diverged recently. I haven't to my
knowledge ever had to work around differences between the two.

Indeed, Safari has had JITed JS for longer than most browsers - this is just
an update.

~~~
Touche
> Safari is basically at feature parity with Chrome

Is this a joke? IndexedDB, WebRTC, etc.?

~~~
matthewmacleod
No, it's not a joke. You've identified two features that are in Chrome that
aren't in Safari. There are a few others - the new filesystem APIs, Shadow DOM
etc. - there are also a few features in Safari that aren't in Chrome, like
MathML and I think CSS region support.

IOW, they aren't far off each other. Safari suffers from a much slower release
cycle in particular - Chrome is usually a few features ahead due to this. Same
with Firefox.

~~~
Touche
Pretty much every game-changing web feature comes to Safari years after
Firefox and Chrome. Yes, they are good at some things, particularly CSS, but
not at the types of things that allow new types of applications to be built.

------
dudus
Why can't they just use v8 or spidermonkey? Why invest time on creating
something that will be only marginally superior (maybe?) than current open
source technologies?

~~~
azakai
It's great that Apple has smart engineers working on this. It's trying out a
new approach that neither v8 or spidermonkey have - to use LLVM as a 4th tier
JIT. This is how interesting things happen.

The world would be a poorer place if we had fewer independent implementations,
as each has its own design and architecture.

~~~
stcredzero
_to use LLVM as a 4th tier JIT_

So, what if this led to a bytecode derived from LLVM IR becoming a universal
bytecode for the web?

