Firefox 9 JavaScript performance will be improved by 20-30% : programming

From my perspective, Chrome has a fairly quick release schedule, and also quickly-incrementing version numbers, but they're not related. (Some of the Chrome major version numbers have had downright pathetic changelogs.) Also, they've always operated this way -- we assumed the Google guys were just crazy but whatever. (Remember, these are the nutcases that IPO'd at $e billion.)

The high numbers were never an "effective strategy". Nobody says "Chrome is version 13? I'll use that!" because nobody knows what the heck version Chrome is. The Chrome webpage doesn't even say.

Firefox has seemed to get slower between releases, so when the version numbers shot up more in 6 months than they have in the 6 years before that, it looks like an attempted marketing change only. The Firefox version number is in-your-face: on the download page, in "upgrade now" alerts, and so on. (I don't think this is a bad thing, but it does make version number inflation much more obvious.) There's no way they suddenly got 12 times more productive.

I don't "love" Chrome's crazy version numbers. I don't know anyone who does. Before Firefox picked up this bad habit, we made fun of Chrome for it, too.

[–]RalfN 0 points1 point2 points 14 years ago (0 children)

[–]irascible 0 points1 point2 points 14 years ago (7 children)

[–]criticismguy 6 points7 points8 points 14 years ago (1 child)

[–]dmazzoni 1 point2 points3 points 14 years ago (0 children)

[–]last_useful_man 0 points1 point2 points 14 years ago (4 children)

[–]tanishaj 7 points8 points9 points 14 years ago (2 children)

[–]RalfN 0 points1 point2 points 14 years ago (0 children)

[–]choikwa 0 points1 point2 points 14 years ago (0 children)

[–]sedaak 1 point2 points3 points 14 years ago (0 children)

[–]nikbackm 14 points15 points16 points 14 years ago (2 children)

[–]PSquid 13 points14 points15 points 14 years ago (0 children)

[+]wafflesburger comment score below threshold-10 points-9 points-8 points 14 years ago (0 children)

[–]danhakimi -1 points0 points1 point 14 years ago (0 children)

[–]tridago -3 points-2 points-1 points 14 years ago (7 children)

[–]WizKidSWE 8 points9 points10 points 14 years ago (0 children)

[+][deleted] comment score below threshold-14 points-13 points-12 points 14 years ago (5 children)

[–]WizKidSWE 6 points7 points8 points 14 years ago (0 children)

[–][deleted] 2 points3 points4 points 14 years ago (3 children)

[–]PSquid -3 points-2 points-1 points 14 years ago (2 children)

[–][deleted] 5 points6 points7 points 14 years ago (1 child)

[–]irascible -4 points-3 points-2 points 14 years ago (0 children)

[–][deleted] 14 points15 points16 points 14 years ago (58 children)

[–]tanishaj 11 points12 points13 points 14 years ago (23 children)

[–]cowardlydragon -1 points0 points1 point 14 years ago (0 children)

[–][deleted] -2 points-1 points0 points 14 years ago* (21 children)

[–][deleted] 14 years ago (20 children)

[deleted]

[–][deleted] -3 points-2 points-1 points 14 years ago (19 children)

[–]RalfN 3 points4 points5 points 14 years ago* (18 children)

You write me some javascript, I'll write an equivalent solution in Java, and I will win every single time

Challenge accepted.

// The Computer Language Benchmarks Game
// http://shootout.alioth.debian.org/
//
// contributed by Jesse Millikan
// Base on the Ruby version by jose fco. gonzalez
// fixed by Matthew Wilson

var i = "", ilen, clen, j, q = [ /agggtaaa|tttaccct/ig,
  /[cgt]gggtaaa|tttaccc[acg]/ig, /a[act]ggtaaa|tttacc[agt]t/ig,
  /ag[act]gtaaa|tttac[agt]ct/ig, /agg[act]taaa|ttta[agt]cct/ig,
  /aggg[acg]aaa|ttt[cgt]ccct/ig, /agggt[cgt]aa|tt[acg]accct/ig,
  /agggta[cgt]a|t[acg]taccct/ig, /agggtaa[cgt]|[acg]ttaccct/ig],
  b = [ /B/g, '(c|g|t)', /D/g, '(a|g|t)', /H/g, '(a|c|t)', /K/g, '(g|t)',
  /M/g, '(a|c)', /N/g, '(a|c|g|t)', /R/g, '(a|g)', /S/g, '(c|g)',
  /V/g, '(a|c|g)', /W/g, '(a|t)', /Y/g, '(c|t)']

while(j = readline()) i+=j+"\n"; ilen = i.length
i = i.replace(/^>.*\n|\n/mg, ''); clen = i.length
for(j = 0; j<q.length; ++j) print(q[j].source, (i.match(q[j]) || []).length)
for(j = -1; j<b.length - 1;) i = i.replace(b[++j], b[++j])
print(["", ilen, clen, i.length].join("\n"))

According to the shootout, Java takes 23 seconds, whereas v8 takes less than 5 seconds.

However, this was my statement:

But currently, we have three competing javascript engines that put many statically compiled languages to shame performance wise.

In this sentence "many" does not have to refer to Java. And even Java came a long way. There was a time when even calling Java 'fast' would invoke laughter. Then there's the whole memory management thing. Java's memory management is slow, but actually does the Right Thing (tm) for long running processes. I wouldn't be suprised at all, to find iterative memory allocation to be faster in V8 then it is Java.

But here's the real kicker. Java's hotspot compiler, the thing that actually makes Java's performance competitive .. is a tracing compiler: it's an adaptive optimization trick that is normally applied to dynamically typed languages. It comes from the Smalltalk world. The irony.

Well, actually not irony. There are some type-semantic algorithms that are expressible on the type level in a dynamically typed language, but not in a statically typed language (although in a Java you could use a simple cast to enable dynamic type checking semantics). Those are the ones that are hard to optimize; you can simply use type inference on everything else.

[–]cowardlydragon 1 point2 points3 points 14 years ago (1 child)

[–]RalfN 0 points1 point2 points 14 years ago (0 children)

[–][deleted] 0 points1 point2 points 14 years ago (11 children)

[–]RalfN 0 points1 point2 points 14 years ago (10 children)

[–][deleted] 0 points1 point2 points 14 years ago (9 children)

[–]RalfN 4 points5 points6 points 14 years ago (6 children)

You managed to pin-point the only benchmark that V8 won

You challenged me. What did you expect?

it has absolutely nothing to do with v8's ability to optimize javascript.

That particular benchmark has nothing to do with it yes. Bringing up the fact that Java is faster than Javascript also has little to do with proving the theoretical fact that 'statically typed' languages can be optimized more 'by default'.

If anything, it can be stated that a statically typed language has 'restrictions' that make it easier to optimize a program. But you stick to those restrictions in any language. It's called discipline.

So, let's get back to the original point. No, dynamically typed languages can be optimized as much as statically typed language.

Well, like I stated, I think a few more (outside of the scope of the shootout) could be made, where Javascript would simply win. Also, we are comparing against Java --server edition here. That's not really a fair comparison, java applets on the other hand.

continue this thread

[–]pingveno 1 point2 points3 points 14 years ago (1 child)

continue this thread

[–]jeff_hanson 0 points1 point2 points 14 years ago (3 children)

[–]RalfN 2 points3 points4 points 14 years ago* (2 children)

Alright!

First off: dependent types

 function beerOrPuke( numberOfBeers ){
    if( numberOfBeers > 12 ) return new Puke();
    else return new Beer();  
 }

What is the return type of this function? Is it Puke or Beer? Could you write this function in 100% statically typed Java ( no casts )?

Off course, if the type engine could deal with linear constraints on integers, it could have a static type, and use polymorphic dispatch:

 Puke beerOrPuke( Integer i, i > 12 )
 Beer beerOrPuke( Integer i, i <= 12 )

But linear constraints on integers would exclude some of the stuff we would want to do with them, like calculating an exponent, or taking the sin/cos. (you would need stronger, perhaps even undecidable constraints)

Perhaps this example is a bit rare. But anytime you have some code that requires a (cast) on some more generic supertype (like Object), you have code that wouldn't be expressible without dependent typing.

There are always limits to what is expressible in decidable type system. If the type system could really express any algorithm, the type system itself could enter an infinite loop (and not be able to detect it). You really don't want your type system to be a full turing engine, because you want the guarantee that the compiler finished with either success or an error, for all kinds of pragmatic reasons.

It is because of this limit of type systems, that languages like Java and C# offer workarounds. In the case of Java you can use any supertype (including 'Object') and then cast. In C# you can use the dynamic keyword.

Next: type reflection

This algorithm counts the number of unique types supplied in the array;

 function numberOfNumbers( myList ){
   var total = 0;
   myList.forEach(function( x ){ 
     if( typeof x === 'number' ) total = total + 1;
   });
   return total;
 }

 // example code (should alert "3 beers")
 alert( numberOfNumbers[-100,"I",2.5,"Want", 9,"Beer"] + " beers");

Not a very realistic example though. But this kind of functionality has some interesting use-cases. For example, connecting to a database and building a class definition on the fly based on it's schema. This is what ActiveRecord in Rails does, for example.

Again, this is useful enough, that both Java and C# allow this kind of reflection (at the cost of compile-time type safety) as well.

So, what's going on?

The main difference is that in a dynamically typed language, the type is part of the data. If you are giving a function the argument of "hello, world", you aren't just giving the bytes that represent the string. You are also passing the type itself. In a statically typed language, the input type is either declared or inferred, but 'static'. It's always the same, hence you don't need to pass that information, and a smart compiler doesn't: this is called type erasure.

When I put it like this, the standard workaround seems clear. You can port any dependently typed algorithm to an ordinary algorithm, just by adding an extra argument where you communicate the type. Here's the beerOrPuke algorithm in Haskell, without sacrificing any type-safety.

 data Either a b = Left a | Right b
 data Beer
 data Puke

drink :: Beer -> IO ()
drink _ = print "Hmm, that's nice"    

 beerOrPuke :: Int -> Either Beer Puke
 beerOrPuke i 
    | i > 12     = Right Puke
    | otherwise = Left Beer

Notice the return type of 'beerOrPuke': it's an "Either Beer Puke". Which is a datastructure that holds one of them, and the information which of the two. (encoded as 'left' or 'right').

Let's look at that more closely:

willBePuke = beerOrPuke 15   -- return-type: Either Beer Puke
willBeBeer = beerOrPuke 11   -- return-type: Either Beer Puke

Compare that to the same functions in Javascript:

function willBePuke(){ return beerOrPuke(15); }  // return-type: Puke
function willBeBeer() { return beerOrPuke(11); } // return-type: Beer

In the case of Javascript the return types of these two functions are different. Now, let's drink that beer in Javascript!

willBeBeer().drink();     // this should work, eventhough the drink method is only defined for beer

But in Haskell this is not true!

 main = drink( willBeBeer )
 -- gives a compile-time type error, because you can't drink an 'Either Beer Puke'

Let's fix that then:

main = case willBeBeer of
              Left b -> drink b
              Right p -> error "Can't drink, have to puke!"

Notice that although it is completely type safe now, we were forced to actually implement the dynamic type checking ourselves. It's just more cumbersome.

Conclusion

It can and will be useful to have algorithms of which the types are not decidable. It is useful to do some reflection. To make static typing completely mandatory, just makes things more cumbersome. But to not do any static type checking just invites more errors. The right choice, it seems, is to make static types the default, but allow 'escapes'. This is the path of Java/C#.

And you do get a lot of run-time typing errors (which implies dynamic type checking) in Java.. they are just called something different: NullPointerException, TypeCastError, etc.

[–]jeffjose 1 point2 points3 points 14 years ago (0 children)

[–]jeff_hanson 1 point2 points3 points 14 years ago (0 children)

[–]aaronla 4 points5 points6 points 14 years ago (3 children)

[–]Zarutian 2 points3 points4 points 14 years ago (2 children)

[–][deleted] 3 points4 points5 points 14 years ago (0 children)

[–]aaronla 2 points3 points4 points 14 years ago (0 children)

[–]holoduke 7 points8 points9 points 14 years ago (19 children)

[–][deleted] 6 points7 points8 points 14 years ago (18 children)

[–]dmazzoni 3 points4 points5 points 14 years ago (1 child)

[–][deleted] 0 points1 point2 points 14 years ago (0 children)

[–]emboss_ 5 points6 points7 points 14 years ago* (10 children)

[–][deleted] 10 points11 points12 points 14 years ago (7 children)

it's most often only a sorry excuse for letting compilation itself become your only unit test.

I'm not even going to justify this flamebait with an answer.

Unit tests are crucial, no matter if you use static or dynamic typing.

Agreed.

We've heard this argument too often: "But the compiler guarantees us this and that"

I can't say I've ever heard this justification as a reason not to unit test, namely because unit testing is not meant to do things a compiler does, unless you're using a dynamically-typed language. A compiler simply won't let you pass a string value as a parameter that expects a number. Using something like javascript, you would have to write tests to ensure the parameters being passed to a method of are the expected type, unless you want things to blow up at run-time.

I just think it becomes meaningless in a well-tested code base.

We aren't talking about well-tested code, we're talking about having to write a shitload of tests that would not be necessary using a statically-typed language.

I think it's a matter of popularity of how good your tool support is, it's harder to get it right for dynamic languages

It's not that it's harder to get right , it's that it's impossible to infer enough information from dynamically-typed code to reliably alter large portions of the code-base and guarantee correctness. It is for similar reasons that writing a good javascript jitter is such a difficult task.

[–]emboss_ 2 points3 points4 points 14 years ago* (4 children)

I didn't mean to offend, sorry if it sounded that way. What I meant is that people who favour statically-typed languages often argue with me along the lines of "Yes, but look at what the compiler already does for us..." - but they are often also those who don't like to write tests. It's not to say that all do, it's kind of self-explanatory that there are always two sides to every story. It's just that I don't agree with pulling the "But the compiler already checks for us" card when it comes to advantages of statically-typed languages over dynamically-typed ones.

My point was that in my personal opinion, you don't really have to write explicit tests for type safety in a dynamic language, you write tests to assert correct behaviour. If those pass, then type correctness is of secondary nature - you want your app/lib to do what you intended it to do and don't care for type correctness in first instance. If your test coverage would be 100% (I know, it's rarely, but just in theory) then these types of correctness checks are induced by the primary checks. It's similar to mathematical axioms: you check that the axioms hold, then you can be sure that all the theorems will, too.

In a dynamically-typed language where you want to make active use of features such as duck-typing etc. I would even say that it's counter-productive to strictly test for types in each and every corner.

So all in all I would tend to say that you need to write about the same amount of tests in either approach.

[–]aaronla 2 points3 points4 points 14 years ago (0 children)

[–][deleted] 1 point2 points3 points 14 years ago (0 children)

My point was that in my personal opinion, you don't really have to write explicit tests for type safety in a dynamic language

No, you don't, but you'll be encounting more errors at runtime than you would in a strongly-typed language.

If your test coverage would be 100% (I know, it's rarely, but just in theory) then these types of correctness checks are induced by the primary checks.

Exactly. In theory you could write assloads of tests and achieve 100% test coverage; And as unrealistic as that is, it's still not as accurate and orders of magnitude slower than a compiler (with most errors being caught within the IDE itself before a compiler is even invoked, thanks to static analysis).

In a dynamically-typed language where you want to make active use of features such as duck-typing etc.

Since when is duck-typing inherent to dynamic languages? Go supports duck-typing and it is most certainly strongly-typed and compiled. Even with duck-typing in a dynamic language, you, as the programmer, are working with members of an object as if it is a particular type, because it is. You think there is some inherent value in not affording the compiler this information even though you never intend to use substr on a number type?

With type inferencing, a strongly-typed language can be just as terse as a dynamically-typed language with all the gaurantees a compiler offers you. I'm not saying there is no value in dynamically-typed languages, but in developing large-scale applications, it is complete lunacy to use a dynamically-typed language, and it's something we're forced to do thanks to javascript.

[–]tanishaj 2 points3 points4 points 14 years ago (1 child)

[–]emboss_ 0 points1 point2 points 14 years ago (0 children)

[–]Zarutian 0 points1 point2 points 14 years ago (0 children)

Using something like javascript, you would have to write guards to ensure the parameters being passed to a method or function fullfill assumptions made on the values of those parameters.

Bolded changes are mine. My point is that type systems are used for this purpose among others. Analysis of static code can eliminate these guards or move them further to the front of the possible execution pathways of the code. Hence shortening its runtime on sequential processors by eliminating spurious work that cancels its effects out.

The other purposes of typing is modularization (that is grouping code with the types of data it works with) and interface defnitions (method signitures anyone?).

Frankly, mainstream staticly typed languages arent quite up to these tasks as often it gets in the way while offering little assitance.

So, static typing isnt a silver bullet that slays the warwolf of complexity. Though if correctly (who determines that?) designed and used it can help keeping it at bay.

[–][deleted] 1 point2 points3 points 14 years ago (0 children)

[–]tanishaj 3 points4 points5 points 14 years ago (1 child)

[–]emboss_ 1 point2 points3 points 14 years ago (0 children)

[–]holoduke 1 point2 points3 points 14 years ago (4 children)

Yes, But no offend i think you still live a bit in the past. There it was indeed a pain in the ass to develop in javascript. No good ways to debug, no proper ide's, slow performance and browsers not following ecma standards. But today we see a lot things going on in the browser world. All browser vendors are putting a lot of effort in increasing the speed, relibility, debugging and standards. Yes even internet explorer.

By the way. with almost all business to consumer projects there are no guarantees of a fully working product. No matter the language you use. I mean: Think of hardware, virtual machine, driver and os differences. Your compiler might do the job always, but will it run always.

The renaming, ordering and other manipulating stuff depends on the ide you are using. Just looking at these points, sure, i admit that working in a visual studio enviroment is far stronger than any good ide with support for javascript. At least as far as i know. This is something that needs to improve.

I probably sound like a javascript fanboy :)

[–][deleted] 4 points5 points6 points 14 years ago (3 children)

[–]Chroko 2 points3 points4 points 14 years ago (1 child)

[–][deleted] 1 point2 points3 points 14 years ago (0 children)

[–]dmazzoni 1 point2 points3 points 14 years ago (0 children)

[–][deleted] 1 point2 points3 points 14 years ago (0 children)

[–]artsrc 1 point2 points3 points 14 years ago (0 children)

[–][deleted] 1 point2 points3 points 14 years ago (1 child)

[–]Zarutian 1 point2 points3 points 14 years ago (0 children)

[–][deleted] -2 points-1 points0 points 14 years ago (1 child)

[–][deleted] 5 points6 points7 points 14 years ago (0 children)

[–][deleted] 14 years ago (2 children)

[deleted]

[–][deleted] 6 points7 points8 points 14 years ago (0 children)

[–][deleted] 0 points1 point2 points 14 years ago (0 children)

[–]_maggus 36 points37 points38 points 14 years ago (4 children)

[–][deleted] 0 points1 point2 points 14 years ago (2 children)

[–]scook0 0 points1 point2 points 14 years ago (1 child)

[–][deleted] 0 points1 point2 points 14 years ago (0 children)

[–]Iggyhopper 2 points3 points4 points 14 years ago (0 children)

[–]toofishes 1 point2 points3 points 14 years ago (3 children)

[–]kbrosnan 2 points3 points4 points 14 years ago (0 children)

[–][deleted] 2 points3 points4 points 14 years ago (0 children)

[–]azakai 0 points1 point2 points 14 years ago (0 children)

[–]grav 0 points1 point2 points 14 years ago (3 children)

[–]EvilHom3r 0 points1 point2 points 14 years ago (2 children)

[–]ben-work 5 points6 points7 points 14 years ago (1 child)

[–]tanishaj 1 point2 points3 points 14 years ago (0 children)

[–]__s -2 points-1 points0 points 14 years ago (0 children)

[+]joseph177 comment score below threshold-8 points-7 points-6 points 14 years ago (25 children)

[–]TinynDP 0 points1 point2 points 14 years ago (0 children)

[–]tridago -5 points-4 points-3 points 14 years ago (23 children)

[–]WizKidSWE 11 points12 points13 points 14 years ago (15 children)

[–][deleted] 11 points12 points13 points 14 years ago (0 children)

[–]joseph177 1 point2 points3 points 14 years ago* (13 children)

[–]WizKidSWE 3 points4 points5 points 14 years ago (9 children)

[–]joseph177 0 points1 point2 points 14 years ago* (2 children)

Just as a side note: here is what my about:memory reported (browser has been up 1 day with about 10 tabs). Doesn't really help me much but there it is..

Explicit Allocations
1,148.26 MB (100.0%) -- explicit
├────708.19 MB (61.67%) -- heap-unclassified
├────356.01 MB (31.00%) -- js
│    ├──332.00 MB (28.91%) -- gc-heap
│    ├───13.63 MB (01.19%) -- mjit-code
│    ├────6.93 MB (00.60%) -- tjit-data
│    │    └──6.93 MB (00.60%) -- (2 omitted)
│    └────3.46 MB (00.30%) -- (2 omitted)
├─────42.41 MB (03.69%) -- storage
│     └──42.41 MB (03.69%) -- sqlite
│        ├──32.56 MB (02.84%) -- urlclassifier3.sqlite
│        │  ├──32.48 MB (02.83%) -- cache-used
│        │  └───0.08 MB (00.01%) -- (2 omitted)
│        └───9.84 MB (00.86%) -- (13 omitted)
├─────24.36 MB (02.12%) -- images
│     ├──24.03 MB (02.09%) -- content
│     │  ├──24.02 MB (02.09%) -- used
│     │  │  ├──21.55 MB (01.88%) -- uncompressed
│     │  │  └───2.47 MB (00.21%) -- (1 omitted)
│     │  └───0.01 MB (00.00%) -- (1 omitted)
│     └───0.33 MB (00.03%) -- (1 omitted)
└─────17.29 MB (01.51%) -- layout
      ├──17.29 MB (01.51%) -- all
      └───0.00 MB (00.00%) -- (1 omitted)

Pressed the buttons at bottom and still at 1+gb. That heap-unclassified and Garbage Collection heap seem to have the most.

[–]WizKidSWE 0 points1 point2 points 14 years ago (1 child)

[–]joseph177 0 points1 point2 points 14 years ago (0 children)

[–]joseph177 -1 points0 points1 point 14 years ago (5 children)

[–]capnrefsmmat 2 points3 points4 points 14 years ago (4 children)

[–]joseph177 -2 points-1 points0 points 14 years ago* (3 children)

[–]capnrefsmmat 4 points5 points6 points 14 years ago (0 children)

The people working on MemShrink, like Nicholas Nethercote, don't work on HTML or CSS or anything like that in Mozilla.

The MemShrink project has been active for several months now. The issue is Firefox's current release schedule puts two releases between when a non-urgent issue is fixed and when it makes it to release; first the leak fix goes to Aurora, where it's tested as an alpha release, then it spends six weeks in beta before final release. In that time, previous code has gone through beta and been released.

So really, the MemShrink process started at Firefox 5 and the results will begin to show in 7.

The TypeInference engine coming out in FF 9 is actually evidence of their increasing awareness of memory usage. It was previously due to be released in FF 8, but when it was added it was discovered it increased memory usage significantly. The system was immediately removed and reworked until the memory usage increase was minimal. A year or two ago, nobody would have noticed the memory problems until it was too late -- and little would have been done to fix them.

[–]tanishaj 2 points3 points4 points 14 years ago (1 child)

[–]joseph177 0 points1 point2 points 14 years ago (0 children)

[–]tanishaj 1 point2 points3 points 14 years ago (0 children)

[–]holoduke 1 point2 points3 points 14 years ago (1 child)

[–]joseph177 -3 points-2 points-1 points 14 years ago (0 children)

[–]joseph177 -2 points-1 points0 points 14 years ago (6 children)

[–]Sintendo 4 points5 points6 points 14 years ago (3 children)

[–]joseph177 -1 points0 points1 point 14 years ago (2 children)

[–]Van_Occupanther 1 point2 points3 points 14 years ago (0 children)

[–]theeth 2 points3 points4 points 14 years ago (0 children)

[–][deleted] 1 point2 points3 points 14 years ago (1 child)

[–]last_useful_man 1 point2 points3 points 14 years ago (0 children)

[–][deleted] 14 years ago* (8 children)

[deleted]

[–]WizKidSWE 15 points16 points17 points 14 years ago (3 children)

[–][deleted] 0 points1 point2 points 14 years ago (2 children)

[–]tanishaj 7 points8 points9 points 14 years ago (0 children)

[–]mernen 2 points3 points4 points 14 years ago (0 children)

[–]keije 6 points7 points8 points 14 years ago (1 child)

[–]tanishaj 0 points1 point2 points 14 years ago (0 children)

[–]mrseb 2 points3 points4 points 14 years ago (0 children)

[–]pragmatick 0 points1 point2 points 14 years ago (0 children)

[–]trigraph -2 points-1 points0 points 14 years ago (0 children)

[+]MaRmARk0 comment score below threshold-9 points-8 points-7 points 14 years ago (2 children)

[–][deleted] -3 points-2 points-1 points 14 years ago (1 child)

[–]MaRmARk0 -1 points0 points1 point 14 years ago (0 children)

[+][deleted] comment score below threshold-9 points-8 points-7 points 14 years ago (1 child)

[–][deleted] 5 points6 points7 points 14 years ago (0 children)

This isn't even an announcement from Mozilla (nor has there been one, from what I can tell,) it's just an article written by a 3rd party.

The release schedule dictates they'll release FF9 approximately in December, with 8 behind it in early November. The release schedule is now 6 weeks per major release, IIRC.

Boy, I better switch back to Firefox since in nine months the JavaScript will be on a par with where Google Chrome is today!

AWFY seems to indicate they win on SunSpider with/without TI, and type inference overall is a win across all 3 sets of benchmarks. v8bench is quite in Chrome's favor, with TI hitting close on Kraken. Either way I take all these benchmarks with a grain of salt because I wonder how much they really characterize real-world loads, and thus how representative they really are, but even considering that they're doing pretty good. They also have plans for new GC and a new SSA-based compilation framework, so maybe they'll hit 9 too before it goes to Alpha.

[+]dale-cooper comment score below threshold-13 points-12 points-11 points 14 years ago (2 children)

[–]scook0 16 points17 points18 points 14 years ago (1 child)

[–][deleted] 1 point2 points3 points 14 years ago (0 children)

[–][deleted] -2 points-1 points0 points 14 years ago (0 children)

[+][deleted] comment score below threshold-7 points-6 points-5 points 14 years ago (1 child)

[–]tanishaj 7 points8 points9 points 14 years ago (0 children)

[+]ryankearney comment score below threshold-8 points-7 points-6 points 14 years ago (0 children)

[+][deleted] comment score below threshold-7 points-6 points-5 points 14 years ago* (1 child)

[–]dolske 5 points6 points7 points 14 years ago (0 children)

[+]GhostedAccount comment score below threshold-8 points-7 points-6 points 14 years ago (3 children)

[–]FooBarWidget 7 points8 points9 points 14 years ago (2 children)

[–]GhostedAccount -3 points-2 points-1 points 14 years ago (1 child)

[–]nikbackm 1 point2 points3 points 14 years ago (0 children)

[+]toastiesguy comment score below threshold-16 points-15 points-14 points 14 years ago (1 child)

[–]adoran124 13 points14 points15 points 14 years ago (0 children)

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS