Re: firefox-4.0.1
On Wed, May 11, 2011 at 09:36:37AM +0200, Witold Baryluk wrote:
> Good work! Keep testing, run some benchmarks please.
> I im interested about improvements from interpreted JS from 3.6
> to interpreted JS in 4.0 :)
I don't have anything formal in the way of benchmarks. However, a web
site I visit regularly has one page in particular where the majority of
the content is dynamically generated and responsive to clicks that
expand/close the content. I still see the pop-up warning message to the
effect of "A script on this page has either stopped or is executing
slowly. Abort? Continue?" I *may* be seeing that message less often
with 4.0.1 than I was with 3.6.X, but I suspect that's due to other
things the browser is definitely doing more efficiently in 4.0.1 than it
was in 3.6.X. The overall footprint in memory feels smaller: I can have
more tabs open, and file-saves are *much* quicker. I wouldn't expect
the JS interpreter to be significantly faster or slower either way: the
developer emphasis would clearly have been on improving JIT performance.
> Any possibility to merge this patches upstream?
Frankly, the patches amount to either workarounds for tool chain
issues, or reversions of xpcom changes that occurred between 3.5.4 and
3.5.5. Bug #586784 at http://bugzilla.mozilla.org was marked
"unverified" and subsequently never investigated with any enthusiasm by
the Mozilla developers: it's still open. I'll probably post an update
sometime this week. If anyone reading this can add any useful
information or at least indicate to Mozilla that more than one user is
affected, that would be helpful. The biggest problem with firefox on
Alpha is that Alpha is a third-tier architecture: bugs on Alpha don't
(and can't) get the attention that, say, x86 bugs will get. From what I
can tell, none of the core Mozilla developers have access to an Alpha.
> As of JIT, it would be quite hard and will took some time.
> JIT in 4.0 is much more improved, but AFAIK Firefox works already
> on next JIT, so this is very moving target. BTW do you know
> if internally this JIT is simpler or more complex than previous one?
I haven't looked at it *too* closely, but I believe the JIT code is
moving in the right direction as far as maintainability. I want to
believe that means it would be easier to add/support new architectures.
> And how well it separate target depended code genration from rest of the engine?
That's what I meant when I mentioned improved maintainability. Whether
that means the JIT code is simpler is debatable, but the organization of
it is better.
> They probably support now i386, amd64, ppc and arm right?
Yes.
> Do they have plans
> for other architectures?
Unknown. It's clear they want the flexibility to be able to support new
architectures if/when they become popular for some definition of
"popular." They will likely accept conforming code for non-first-tier
architectures, but maintenance of the submitted code will probably fall
on whoever submits it. While I would love to see JIT support for Alpha,
I'm probably not going to be the person that does it -- certainly not as
a solo effort: I'm lacking too many needed resources (fast machine, time).
--Bob
Reply to: