10 replies to this topic

[chucktdriscoll]

There still seems to be a lot of questions about JIT.  Here's a little primer about it.

JIT stands for Just In Time.  It's an on the fly compiler for Java.  Since Java is a byte-compiled language that runs in a virtual machine the code generated is machine independent.  This results in slower execution than traditional compiled languages like C/C++ because the virtual machine has to convert all commands into their lower level equivalent based on the hardware that it's running on.  JIT mitigates some of this overhead by converting (some of) the Java byte-code into actual machine code for the current hardware (arm6, arm7, x86, etc.).  While this seems like an excellent idea, it usually doesn't provide the "performance" improvements that some people expect on their android devices.  The reason nothing "feels" faster is because JIT will only provide improvement for tasks that require large amounts of CPU time.  Almost no android apps require that much CPU time.  Some apps may make heavy use of the GPU, but JIT doesn't help there.  Other apps perform a lot of input/output which is terribly slow.  JIT can't help there either.  On some devices JIT may actually reduce performance because it will consume more RAM to store the native machine code that it generates.

Not very well written, but you'll have to excuse that.  I may rewrite that when I'm a little more awake, but you get the point.  CPU intensive tasks get faster, but at the cost of RAM.  Most android lag is due to IO which can't benefit from JIT.  Feel free to use -Stevo-'s script to try JIT out and see if it helps for you, but don't expect miracles.

PS.  Froyo will have JIT as a core part of the system.  That JIT is an updated version of the one in Eclair that may result in more noticeable gains.  Wait and see.

[StephanV]

Very interesting read, thanks!

[Codenomics]

So is the browser considered to be a heavy CPU app? I think the only difference I noticed was while loading web pages, but that might have been something else.

[castaway]

can JIT be reason why launcher will restart often when i going back to home?

[Ed Boy]

castaway, on 11 June 2010 - 09:35 AM, said:

can JIT be reason why launcher will restart often when i going back to home?

That would seem to be a logical result; if you run a cpu heavy application JIT uses RAM to store the machine code generated; this reduces the RAM available for keeping launcher in memory.

I'm no expert but you might see this kind of thing via adb logcat -

I/ActivityManager(  143): Low Memory: No more background processes.

This happens without JIT but will probably increase under JIT.

So it's swings and round-a-bouts, what you gain on the CPU: you lose on the RAM.

I tried JIT and had more trouble from this effect than i gained benefit from having some tasks running faster.

[chucktdriscoll]

Codenomics, on 11 June 2010 - 04:48 AM, said:

So is the browser considered to be a heavy CPU app? I think the only difference I noticed was while loading web pages, but that might have been something else.

JIT can show some improvement in the browser.  Drawing 2d images to the screen and parsing html can be a little cpu intensive.

Ed Boy, on 11 June 2010 - 12:09 PM, said:

That would seem to be a logical result; if you run a cpu heavy application JIT uses RAM to store the machine code generated; this reduces the RAM available for keeping launcher in memory.

I'm no expert but you might see this kind of thing via adb logcat -

I/ActivityManager(  143): Low Memory: No more background processes.

This happens without JIT but will probably increase under JIT.

So it's swings and round-a-bouts, what you gain on the CPU: you lose on the RAM.

I tried JIT and had more trouble from this effect than i gained benefit from having some tasks running faster.

Exactly correct.  Enabling compcache and "Launcher in memory" in spare parts can help reduce this problem, but not eliminate it.  Swap can also help prevent launcher from being killed, but I usually don't recommend swap for a number of reasons.  Some people swear by it however so try it if you have problems and turn it off if your problems don't go away (or new ones appear).

[castaway]

Ed Boy, on 11 June 2010 - 12:09 PM, said:

That would seem to be a logical result; if you run a cpu heavy application JIT uses RAM to store the machine code generated; this reduces the RAM available for keeping launcher in memory.

I'm no expert but you might see this kind of thing via adb logcat -

I/ActivityManager(  143): Low Memory: No more background processes.

This happens without JIT but will probably increase under JIT.

So it's swings and round-a-bouts, what you gain on the CPU: you lose on the RAM.

I tried JIT and had more trouble from this effect than i gained benefit from having some tasks running faster.

thx for explanation
i try it and yes i geting lot
I/ActivityManager<255> Low memory:no more background processes
so i think one solution is take out JIT.And yes i have compcache ON and launcher in memory. But this happen in 90% when i go to browser load page then for example to ASTRO file manager and back to home.

[chucktdriscoll]

castaway, on 11 June 2010 - 12:39 PM, said:

thx for explanation
i try it and yes i geting lot
I/ActivityManager<255> Low memory:no more background processes
so i think one solution is take out JIT.And yes i have compcache ON and launcher in memory. But this happen in 90% when i go to browser load page then for example to ASTRO file manager and back to home.

What kind of phone do you have?  Browser can tie up quite a bit of ram, but I havent' seen launcher getting killed that often on my Mytouch 1.2 with JIT.  A G1 or 32b Magic would obviously see more low memory errors than a 32a.  Do you have ADW's "wallpaper hack" turned on?  And what resolution is the wallpaper you're using?  High res wallpapers and "wallpaper hack" together will cause adw.launcher to fill a larger portion of ram which could result in android killing it more often.  Resizing any images you use for wallpaper to 640x480 will help.  "Wallpaper hack" will make adw smoother, but cause it to eat some extra ram (the total ram used doesn't change, more is allocated to adw directly instead of to the Eclair wallpaper manager).  Experiment till you find what works best for you.

[castaway]

chucktdriscoll, on 11 June 2010 - 12:50 PM, said:

What kind of phone do you have?  Browser can tie up quite a bit of ram, but I havent' seen launcher getting killed that often on my Mytouch 1.2 with JIT.  A G1 or 32b Magic would obviously see more low memory errors than a 32a.  Do you have ADW's "wallpaper hack" turned on?  And what resolution is the wallpaper you're using?  High res wallpapers and "wallpaper hack" together will cause adw.launcher to fill a larger portion of ram which could result in android killing it more often.  Resizing any images you use for wallpaper to 640x480 will help.  "Wallpaper hack" will make adw smoother, but cause it to eat some extra ram (the total ram used doesn't change, more is allocated to adw directly instead of to the Eclair wallpaper manager).  Experiment till you find what works best for you.

Im using 32B magic.
i solve my problem by trash out
pure grid calendar widget
pure calendar widget
pure messanger widget
weather forecast widget

everything is now smoot and fast just one launcher restart in a lot testing..its all about widgets i miss them so much thx for your help i will play a bit with swap compcache overclock wallpapers as you say thx a lot for help and finaly explanation about JIT.

[chucktdriscoll]

castaway, on 11 June 2010 - 02:15 PM, said:

Im using 32B magic.
i solve my problem by trash out
pure grid calendar widget
pure calendar widget
pure messanger widget
weather forecast widget

everything is now smoot and fast just one launcher restart in a lot testing..its all about widgets i miss them so much thx for your help i will play a bit with swap compcache overclock wallpapers as you say thx a lot for help and finaly explanation about JIT.

Ahh yes.  Forgot about the widgets.  Those fabulous eaters of ram.  So pretty and useful, but also so resource hungry.

[DackParis]

thanks for that