Live data from Hacker News

Why is the mobile web slow?

codenameone.com

41–48 of 48 posts

Re: Why is the mobile web slow?

#41
post #40
post #36

Earlier quoted context omitted.

From the few times I tried to read Android code, I think the JIT is not touched since Android 2.3. I am still curious what Google is going to do with Java and Dalvik, as the whole thing seems to be frozen since the whole process with Oracle, and they only add new APIs. The last two Google IOs did not have any Dalvik related talk.

It's unclear if Dalvik's JIT compiler needs updating. For non-mobile uses like GoogleTV, it might be worth making a much more aggressive JIT compiler, since battery use would not be an issue. Other than that, it seems like changes would have a small benefit, a large risk, and a very large testing burden. Android is, still, a very lean project inside and lean corporate structure. If it's a third of the way down the pr…

> It's unclear if Dalvik's JIT compiler needs updating.

Well the people doing games already gave up on it since the NDK is available, but given that Google gives a second class treatment to the folks using the NDK, it would be nice if they cared to improve the JIT.

Re: Why is the mobile web slow?

#42
post #30

Earlier quoted context omitted.

Ah, but if you're going to talk about multi-threaded applications, we're going to have to start talking about things like thread-safe reference counts...

You certainly have to be careful passing data between threads in ObjC (though, of course, you do in Java, too); the real problem with managed memory in multi-threaded highly latency sensitive UI applications, though, is that a thread other than the UI thread can happily trigger a stop the world collection through allocation, and it's very difficult for the UI thread to say "I'm doing something important for now; plea…

A nightmare? Is it hard/impossible to wrap the allocation function with a boolean check and a spin in ObjC?

Re: Why is the mobile web slow?

#43
post #41
post #40

Earlier quoted context omitted.

It's unclear if Dalvik's JIT compiler needs updating. For non-mobile uses like GoogleTV, it might be worth making a much more aggressive JIT compiler, since battery use would not be an issue. Other than that, it seems like changes would have a small benefit, a large risk, and a very large testing burden. Android is, still, a very lean project inside and lean corporate structure. If it's a third of the way down the pr…

> It's unclear if Dalvik's JIT compiler needs updating. Well the people doing games already gave up on it since the NDK is available, but given that Google gives a second class treatment to the folks using the NDK, it would be nice if they cared to improve the JIT.

Android contains a variety of performance strategies: Dalvik's JIT is transparent to the developer and it provides a performance boost for most Java apps, Renderscript is for compute-intensive operations. The NDK enables native code modules and makes it fairly convenient to support multiple architectures. Somewhere in there you should be able to find what you need. But I really don't see why anyone developing action games for a multi-threaded, multi-tasking Java OS isn't aware they are going to find it difficult to get a consistently performing game loop. Android just isn't designed for that. Perhaps if Google is really thinking of making a console, they will provide game-oriented scheduling.

Re: Why is the mobile web slow?

#44
post #25

Earlier quoted context omitted.

Though, while Java can, it looks like Dalvik generally does not (though, most of the info available seems to be 2.3-era; possibly things have improves since). It looks like 2.3 Dalvik can inline getters and setters, but it's certainly no Hotspot.

Dalvik is designed around criteria that are nearly diametrically opposed to those for Hotspot. Hotspot goes for maximum performance. Dalvik's JIT compiler is designed for maximum impact on performance with minimum computation. In other words, Dalvik's JIT is designed for battery powered devices.

Depends on what you mean by 'Hotspot'. Both of Sun's embedded JVMs (CDC, CLDC) had 'Hotspot' implementations. Both of these implementations performed many of these types of optimizations (which I can say with certainty because I wrote many of them). I'm no Dalvik expert, but there really isn't any reason why it shouldn't be able to do similar optimizations. Remember that the CDC and CLDC Hotspot implementations were originally developed for hardware of the early 2000s.

Re: Why is the mobile web slow?

#45
post #43
post #41

Earlier quoted context omitted.

> It's unclear if Dalvik's JIT compiler needs updating. Well the people doing games already gave up on it since the NDK is available, but given that Google gives a second class treatment to the folks using the NDK, it would be nice if they cared to improve the JIT.

Android contains a variety of performance strategies: Dalvik's JIT is transparent to the developer and it provides a performance boost for most Java apps, Renderscript is for compute-intensive operations. The NDK enables native code modules and makes it fairly convenient to support multiple architectures. Somewhere in there you should be able to find what you need. But I really don't see why anyone developing action…

I see you are well informed about Android. :)

Sure we can find how way around what is provided, but the performance story could be made better, specially when compared what is given to us in iOS and Windows Phone 8 environments.

Re: Why is the mobile web slow?

#46

> Objective-C doesn't use methods like Java/C++/C#, it uses messages like Smalltalk. This effectively means it always performs late binding and invoking a message is REALLY slow in Objective-C. Well, "always" is a little wrong. The first time a message is passed and the bound method is called by the runtime is significantly slower (~4x slower than a virtual method call in C++). But then this message/method pair gets…

[deleted]

Re: Why is the mobile web slow?

#48

> In fact JavaScript can't technically perform slowly since it is for most intents and purposes single threaded... so long running JavaScript code that will take 50 seconds just won't happen... It's a valid point that almost nobody's writing 50-second raytracing routines in JavaScript, but it's trivial to run code that's executed in the background without freezing your app, by repeatedly calling it with setTimeout().…

This is where Web Workers [1] come in. You shouldn't be performing background processing in a way that blocks the UI. Heavy lifting like that should be pushed into the background, if it's done on the front-end at all.

[1] https://en.wikipedia.org/wiki/Web_Workers

Post reply on HN