javascript is not java, which doesn't necesarily need a vm. It is dynamic,
but not a vm based language


2014-05-12 0:34 GMT+08:00 李白|字一日 <calid...@gmail.com>:

> please have a look at this.
> http://www.reddit.com/comments/1jw6h7
>
> seems dalvik is slower.
>
> 2014-05-11 22:28 GMT+08:00 Kristopher Micinski <krismicin...@gmail.com>:
>
> 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 a topic in the
>> Google Groups "Android Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/android-developers/4UrtNOPympc/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> android-developers+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
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.

Reply via email to