yeah - if there are calculations being performed in js - sure, this will help lots. But from my experience building large hairy ajax apps, its *still* the dom manipulation that holds things back for most everyday things.
But yes, in future, that could well be a bottleneck too. On Sep 2, 8:36 pm, Casper Bang <[EMAIL PROTECTED]> wrote: > I understand what you mean but also seem to have noticed JavaScript/ > Ajax really starting to push the envelope and deliver visuals > ironically enough originally envisioned for the parent language Java. > Case of point:http://www.classycode.co.uk/CoverFlow/ > > /Casper > > On Sep 2, 5:26 am, Michael Neale <[EMAIL PROTECTED]> wrote: > > > yeah their description of JIT may have made sense once, but any jit > > that goes beyond the initial stage of timing methods would go beyond > > it pretty quickly. > > > This is also a good example of a straw man argument (if it was an > > argument). > > > On the subject though, I don't think its JS performance that hurst RIA/ > > web apps - its the browsers performance with respect to DOM, not the > > time spent (in most cases) in script. > > > So I don't think this stuff is much of a big deal for web apps (unless > > actually JS performance was an issue for you). For most of the world. > > its dom manipulation which has nothing to do with this (unless they > > start implementing the browser itself in JS, which is possible). > > > On Sep 1, 12:53 am, Joshua Marinacci <[EMAIL PROTECTED]> wrote: > > > > Hotspot is *not* a traditional JIT compiler. While that was true in > > > the early days of HotSpot (many years ago) today it does lots of > > > advanced realtime prediction and analysis. I would say that HotSpot > > > is the most advanced general purpose VM today, and it's constantly > > > being improved. Where I see real competition coming is special purpose > > > VMs; like things that will optimize your code into a pixel shader, or > > > that do crazy automatic parallelization, or that focus on energy > > > consumption over everything else. > > > > I think they just mention Java's VM because it's the one most people > > > are familiar with. If the CLR was more commonly used they would have > > > mentioned that instead. :) > > > > On Aug 31, 2008, at 3:44 AM, sherod wrote: > > > > > Java gets the (usual) dishonorable mention with Mozilla implying that > > > > their tracing JIT compiler is superior to the JIT solution in Java. > > > > > Anybody with stronger experience than I with this stuff care to > > > > comment? > > > > > *Start quote* > > > > > Traditional just-in-time compilers (like Sun’s Hotspot VM) are in > > > > their design and structure very similar to static compilers (like > > > > GCC). They observe which methods get executed frequently, and > > > > translate the method into native machine code once a certaint > > > > threshold has been reached. While such methods often contain > > > > performance-critical parts (such as loops), they often also contain > > > > slow paths and non-loopy code, which barely if at all contributes to > > > > the runtime of the method. A whole-method compiler, however, has to > > > > always analyze and translate the entire method, even if parts of it > > > > are not particularly “compilation-worthy”. > > > > > Trace-based compilation takes a very different approach. We monitor > > > > the interpretation of bytecode instruction by the virtual machine and > > > > scan for frequently taken backwards branches, which are an indicator > > > > for loops in the underlying program. Once we identify such a loop > > > > start point, we follow the interpreter as it executes the program and > > > > record the sequence of bytecode instructions that get executed along > > > > the way. Since we start at a loop header, the interpreter will > > > > eventually return to this entry point once it completed an iteration > > > > through the loop. The resulting linear sequence of instructions is > > > > what we call a trace. > > > > > *end quote* > > > > > Rest of the article here: > > > > >http://www.infoq.com/news/2008/08/tracemonkey --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
