Android emulator is very very very slow........
How can we developer application on such emulator?
And also I compare same application both on J2ME SUN WTK2.5.1, Android
takes almost 3 times to run the same application.
Just don't understand how Android make such emulator so slow.
Try running it on a machine with at least 3 to 4 Ghz CPU, and 1GB ram.
Another solution to make it faster, is to close eclipse.
You should also time our application, to see where and why they are
slow.
Systems are not alike, some choices may be a good compromise in one
system but not on another.
Check the Performance guidelines that Google have posted somewhere on
the documentation.
NOTE: Emulators by definition are slow :(
On Feb 28, 5:51 pm, drhu00 <drh...@gmail.com> wrote:
> Android emulator is very very very slow........
> How can we developer application on such emulator?
> And also I compare same application both on J2ME SUN WTK2.5.1, Android
> takes almost 3 times to run the same application.
> Just don't understand how Android make such emulator so slow.
I am pretty sure with J2ME you are running code with an interpreter
that is running on the desktop machine. The android emulator, in
contrast, is a low-level ARM emulator, running an actual ARM linux
kernel along with ARM JVM. This makes it slower, but ensures it will
behave very much like a real device.
On Feb 28, 9:51 am, drhu00 <drh...@gmail.com> wrote:
> Android emulator is very very very slow........
> How can we developer application on such emulator?
> And also I compare same application both on J2ME SUN WTK2.5.1, Android
> takes almost 3 times to run the same application.
> Just don't understand how Android make such emulator so slow.
> I am pretty sure with J2ME you are running code with an interpreter
> that is running on the desktop machine. The androidemulator, in
> contrast, is a low-level ARMemulator, running an actual ARM linux
> kernel along with ARM JVM. This makes it slower, but ensures it will
> behave very much like a real device.
> On Feb 28, 9:51 am, drhu00 <drh...@gmail.com> wrote:
> > Androidemulatoris very very veryslow........
> > How can we developer application on suchemulator?
> > And also I compare same application both on J2ME SUN WTK2.5.1, Android
> > takes almost 3 times to run the same application.
> > Just don't understand how Android make suchemulatorsoslow.
> I agree drhu00 - a spacecraftemulatoris much faster than this in
> andoid m5...
> On Feb 28, 5:15 pm, hackbod <hack...@gmail.com> wrote:
> > I am pretty sure with J2ME you are running code with an interpreter
> > that is running on the desktop machine. The androidemulator, in
> > contrast, is a low-level ARMemulator, running an actual ARM linux
> > kernel along with ARM JVM. This makes it slower, but ensures it will
> > behave very much like a real device.
> > On Feb 28, 9:51 am, drhu00 <drh...@gmail.com> wrote:
> > > Androidemulatoris very very veryslow........
> > > How can we developer application on suchemulator?
> > > And also I compare same application both on J2ME SUN WTK2.5.1, Android
> > > takes almost 3 times to run the same application.
> > > Just don't understand how Android make suchemulatorsoslow.
I have same problem because of my very old machine :(
But version m3-rc22a is siginicant faster than m3-rc37a or newer
versions.
If you don't need some of the new features, you can try it, it will
help :)
And remember, that JME applications run much faster on real phone
(e.g. ARM 200-300 Mhz) than on WTK Emulator (e.g. Pentium 1800 Mhz).
On 28 Feb., 18:51, drhu00 <drh...@gmail.com> wrote:
> Android emulator is very very very slow........
> How can we developer application on such emulator?
> And also I compare same application both on J2ME SUN WTK2.5.1, Android
> takes almost 3 times to run the same application.
> Just don't understand how Android make such emulator so slow.
> I have same problem because of my very old machine :(
> But version m3-rc22a is siginicant faster than m3-rc37a or newer
> versions.
> If you don't need some of the new features, you can try it, it will
> help :)
> And remember, that JME applications run much faster on real phone
> (e.g. ARM 200-300 Mhz) than on WTK Emulator (e.g. Pentium 1800 Mhz).
> On 28 Feb., 18:51, drhu00 <drh...@gmail.com> wrote:
> > Android emulator is very very very slow........
> > How can we developer application on such emulator?
> > And also I compare same application both on J2ME SUN WTK2.5.1, Android
> > takes almost 3 times to run the same application.
> > Just don't understand how Android make such emulator so slow.
I expected a release to be better than the previous but the new
release is really annoying. I understand that you can always use the
old faster release but i want to use the new features and changes so
that i I can keep up with the changes in android. I had a whole
project planned to be implemented in android but i guess it is not
ready for it yet . . I will wait for a couple of releases if the
development envinronment is a bit more stable and more important, a
faster emulator. Its just frustrating to develop applications under
these conditions . .
I can only agree. Startup and generally running aplications is soooo
slow. Especially in debug mode :( It is very easy to loose the
interest in programming for Android if the emulator is so slow. I
might have a quite old notebook, but it still run on a 1GHz CPU * 1,5
GB of RAM. I kind of expected better performance and I agree that the
new release got slower :(
Closing eclipse to speed things up is not really an option during
development. Is there nothing else one could do?
Emulator is open-source. Find people in community to optimize it. At
speed at which is running, probably has no JIT. JIT is first thing I
would look at.
On Mar 20, 7:05 am, Hardy <hardy.ferentsc...@gmail.com> wrote:
> I can only agree. Startup and generally running aplications is soooo
> slow. Especially in debug mode :( It is very easy to loose the
> interest in programming for Android if the emulator is so slow. I
> might have a quite old notebook, but it still run on a 1GHz CPU * 1,5
> GB of RAM. I kind of expected better performance and I agree that the
> new release got slower :(
> Closing eclipse to speed things up is not really an option during
> development. Is there nothing else one could do?
the emulator is based on QEMU has a JIT. more specifically an ARM-to-x86 dynamic code generator. the problem is that some operations are very slow because we not only translate the CPU instructions, we also need to emulate a complete ARM memory-management unit, plus lots of other funky features.
e.g. while an ARM memory read requires only a couple cycles, the corresponding emulation requires some complex hash table lookups that take a lot more instructions on the host.
with a scheme like this, it's really hard to adequately emulate a 300 MHz device on a 1 GHz x86 CPU because the CPU speed ratio is so small, and memory emulation (softmmu) is killing you.
you would be surprised at how slow interpretation would work (I think we started with this before switching to QEMU) :-)
On Thu, Mar 20, 2008 at 3:30 PM, vladimir.schlott.andr...@gmail.com <
> Emulator is open-source. Find people in community to optimize it. At > speed at which is running, probably has no JIT. JIT is first thing I > would look at.
> On Mar 20, 7:05 am, Hardy <hardy.ferentsc...@gmail.com> wrote: > > I can only agree. Startup and generally running aplications is soooo > > slow. Especially in debug mode :( It is very easy to loose the > > interest in programming for Android if the emulator is so slow. I > > might have a quite old notebook, but it still run on a 1GHz CPU * 1,5 > > GB of RAM. I kind of expected better performance and I agree that the > > new release got slower :(
> > Closing eclipse to speed things up is not really an option during > > development. Is there nothing else one could do?
How about using x86 features for virtualization? vmware and clones run
pretty fast.
Also, maybe with direct dalvik -> x86 execution (would just be driver
at bottom of kernel) would be acceptable. If much faster than real
phone, can always slow it down to be realistic.
On Mar 20, 7:42 am, Digit <digit.andr...@gmail.com> wrote:
> the emulator is based on QEMU has a JIT. more specifically an ARM-to-x86
> dynamic code generator.
> the problem is that some operations are very slow because we not only
> translate the CPU instructions,
> we also need to emulate a complete ARM memory-management unit, plus lots of
> other funky features.
> e.g. while an ARM memory read requires only a couple cycles, the
> corresponding emulation requires
> some complex hash table lookups that take a lot more instructions on the
> host.
> with a scheme like this, it's really hard to adequately emulate a 300 MHz
> device on a 1 GHz x86 CPU because
> the CPU speed ratio is so small, and memory emulation (softmmu) is killing
> you.
> you would be surprised at how slow interpretation would work (I think we
> started with this before switching to QEMU) :-)
> On Thu, Mar 20, 2008 at 3:30 PM, vladimir.schlott.andr...@gmail.com <
> > Emulator is open-source. Find people in community to optimize it. At
> > speed at which is running, probably has no JIT. JIT is first thing I
> > would look at.
> > On Mar 20, 7:05 am, Hardy <hardy.ferentsc...@gmail.com> wrote:
> > > I can only agree. Startup and generally running aplications is soooo
> > > slow. Especially in debug mode :( It is very easy to loose the
> > > interest in programming for Android if the emulator is so slow. I
> > > might have a quite old notebook, but it still run on a 1GHz CPU * 1,5
> > > GB of RAM. I kind of expected better performance and I agree that the
> > > new release got slower :(
> > > Closing eclipse to speed things up is not really an option during
> > > development. Is there nothing else one could do?
virtualization only works when both environment have the same CPU, which is not the case for the SDK. (and QEMU now supports that very well too, it's just that it's unusable in our context).
dalvik can be run on x86 pretty well, the real issue is being able to emulate all the things that run in a typical device as well, with exactly the same native binaries than the one that are going to ship.
On Thu, Mar 20, 2008 at 3:50 PM, vladimir.schlott.andr...@gmail.com <
> How about using x86 features for virtualization? vmware and clones run > pretty fast.
> Also, maybe with direct dalvik -> x86 execution (would just be driver > at bottom of kernel) would be acceptable. If much faster than real > phone, can always slow it down to be realistic.
> On Mar 20, 7:42 am, Digit <digit.andr...@gmail.com> wrote: > > the emulator is based on QEMU has a JIT. more specifically an ARM-to-x86 > > dynamic code generator. > > the problem is that some operations are very slow because we not only > > translate the CPU instructions, > > we also need to emulate a complete ARM memory-management unit, plus lots > of > > other funky features.
> > e.g. while an ARM memory read requires only a couple cycles, the > > corresponding emulation requires > > some complex hash table lookups that take a lot more instructions on the > > host.
> > with a scheme like this, it's really hard to adequately emulate a 300 > MHz > > device on a 1 GHz x86 CPU because > > the CPU speed ratio is so small, and memory emulation (softmmu) is > killing > > you.
> > you would be surprised at how slow interpretation would work (I think we > > started with this before switching to QEMU) :-)
> > On Thu, Mar 20, 2008 at 3:30 PM, vladimir.schlott.andr...@gmail.com <
> > > Emulator is open-source. Find people in community to optimize it. At > > > speed at which is running, probably has no JIT. JIT is first thing I > > > would look at.
> > > On Mar 20, 7:05 am, Hardy <hardy.ferentsc...@gmail.com> wrote: > > > > I can only agree. Startup and generally running aplications is soooo > > > > slow. Especially in debug mode :( It is very easy to loose the > > > > interest in programming for Android if the emulator is so slow. I > > > > might have a quite old notebook, but it still run on a 1GHz CPU * > 1,5 > > > > GB of RAM. I kind of expected better performance and I agree that > the > > > > new release got slower :(
> > > > Closing eclipse to speed things up is not really an option during > > > > development. Is there nothing else one could do?
> virtualization only works when both environment have the same CPU, which is
> not the case for the SDK.
> (and QEMU now supports that very well too, it's just that it's unusable in
> our context).
> dalvik can be run on x86 pretty well, the real issue is being able to
> emulate all the things that run in a typical device as well,
> with exactly the same native binaries than the one that are going to ship.
> On Thu, Mar 20, 2008 at 3:50 PM, vladimir.schlott.andr...@gmail.com <
> > How about using x86 features for virtualization? vmware and clones run
> > pretty fast.
> > Also, maybe with direct dalvik -> x86 execution (would just be driver
> > at bottom of kernel) would be acceptable. If much faster than real
> > phone, can always slow it down to be realistic.
> > On Mar 20, 7:42 am, Digit <digit.andr...@gmail.com> wrote:
> > > the emulator is based on QEMU has a JIT. more specifically an ARM-to-x86
> > > dynamic code generator.
> > > the problem is that some operations are very slow because we not only
> > > translate the CPU instructions,
> > > we also need to emulate a complete ARM memory-management unit, plus lots
> > of
> > > other funky features.
> > > e.g. while an ARM memory read requires only a couple cycles, the
> > > corresponding emulation requires
> > > some complex hash table lookups that take a lot more instructions on the
> > > host.
> > > with a scheme like this, it's really hard to adequately emulate a 300
> > MHz
> > > device on a 1 GHz x86 CPU because
> > > the CPU speed ratio is so small, and memory emulation (softmmu) is
> > killing
> > > you.
> > > you would be surprised at how slow interpretation would work (I think we
> > > started with this before switching to QEMU) :-)
> > > On Thu, Mar 20, 2008 at 3:30 PM, vladimir.schlott.andr...@gmail.com <
> > > > Emulator is open-source. Find people in community to optimize it. At
> > > > speed at which is running, probably has no JIT. JIT is first thing I
> > > > would look at.
> > > > On Mar 20, 7:05 am, Hardy <hardy.ferentsc...@gmail.com> wrote:
> > > > > I can only agree. Startup and generally running aplications is soooo
> > > > > slow. Especially in debug mode :( It is very easy to loose the
> > > > > interest in programming for Android if the emulator is so slow. I
> > > > > might have a quite old notebook, but it still run on a 1GHz CPU *
> > 1,5
> > > > > GB of RAM. I kind of expected better performance and I agree that
> > the
> > > > > new release got slower :(
> > > > > Closing eclipse to speed things up is not really an option during
> > > > > development. Is there nothing else one could do?
another trivial point to make is to make sure that you disable your AntiVirus for the SDK's emulator.exe binary in one specific instance, (2.66 GHz Celeron, 512 MB), it reduced the boot sequence by 15 seconds (out of 2 minutes)
(some anti-virus programs really don't like programs that generate machine code at runtime)
On Thu, Mar 20, 2008 at 3:42 PM, Digit <digit.andr...@gmail.com> wrote: > the emulator is based on QEMU has a JIT. more specifically an ARM-to-x86 > dynamic code generator. > the problem is that some operations are very slow because we not only > translate the CPU instructions, > we also need to emulate a complete ARM memory-management unit, plus lots > of other funky features.
> e.g. while an ARM memory read requires only a couple cycles, the > corresponding emulation requires > some complex hash table lookups that take a lot more instructions on the > host.
> with a scheme like this, it's really hard to adequately emulate a 300 MHz > device on a 1 GHz x86 CPU because > the CPU speed ratio is so small, and memory emulation (softmmu) is > killing you.
> you would be surprised at how slow interpretation would work (I think we > started with this before switching to QEMU) :-)
> On Thu, Mar 20, 2008 at 3:30 PM, vladimir.schlott.andr...@gmail.com < > vladimir.schlott.andr...@gmail.com> wrote:
> > Emulator is open-source. Find people in community to optimize it. At > > speed at which is running, probably has no JIT. JIT is first thing I > > would look at.
> > On Mar 20, 7:05 am, Hardy <hardy.ferentsc...@gmail.com> wrote: > > > I can only agree. Startup and generally running aplications is soooo > > > slow. Especially in debug mode :( It is very easy to loose the > > > interest in programming for Android if the emulator is so slow. I > > > might have a quite old notebook, but it still run on a 1GHz CPU * 1,5 > > > GB of RAM. I kind of expected better performance and I agree that the > > > new release got slower :(
> > > Closing eclipse to speed things up is not really an option during > > > development. Is there nothing else one could do?
