First of all, this is just downright false, JS *will* be slower than Java, but I'll address each of your points.
On Sun, May 11, 2014 at 12:51 AM, 李白|字一日 <calid...@gmail.com> wrote: > thanks for the reply. > > but i may think differently. > > javascript runtime can be shared, and no new memory allocation and memory > copying required, only the apps require new memories when running. The Android runtime is also shared, common memory pages are mapped between processes. This is the idea behind the "zygote" process, which loads the VM in an initial process and then forks off new processes, and due to copy on write (among other things) the VM is never copied. Apps only require the new memory they need. You can't just slam them all together in the same process, because that will completely destroy security and that will never happen. By the way, the same thing exists in JavaScript for multiple JavaScript tabs. > but the android vm is not, at least you should allocation memory for > inter-media code files like .class files. > then allocate new memory for the vm and then allocate for the app. As I said, you don't allocate any new memory for the VM because of the zygote. You have to allocate pages to keep track of the code, but you also do this with JS, but it's way worse because you need extra stuff to do all the data structures for interpretation / JIT. > for java multi-threading, you may need extra memory to providing more stacks > and extra execution on how to coordinating the threads. > > but javascript may need only one thread, and no threads switching needed, it > is event based. You'll still need threads in JavaScript to make anything efficient. > webkit and javascript event model is native implemented (using c/c++) and vm > free, while java sdk is compiled in java code and interpreted to native. There are open source Java compilers. AOSP is open source. > html and javascript files are translated to native code or natived > implemented interpretors when loaded. The same thing happens right now. > so i think java is by no means faster than javascript, especially when you > have very complicated interactions. It's up for debate, but your arguments for it don't show this. There are tricks to make this work, http://en.wikipedia.org/wiki/Firefox_OS does them. However, JS doesn't have any inherent performance advantages over Java: it's slower if implemented badly. > From all the above, i would like to say that javascript is easy and fast to > load and run, while java is slow to load and run. > if that is true, i think that is the great performance gain. > > java server side is fast in that java programs have loaded and they are all > in memory and servers always provide large memory spaces, we can ignore the > loading and rebooting time it requires, but android is not for server side > programming, it may not have large memory space for too many apps and users > don't have patient to wait too long for starting a new app. Many apps are compiled natively or with a JIT, this is the exact same as JavaScript. Kris -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
