~robcee/ more than just sandwiches

Lorentz Branch Diagram

I was asked this morning if “Lorentz was trunk”. Or a branch of trunk. Or something. So I decided to draw a little picture.

Electrolysis (e10s) feeds patches to Mozilla-Central (trunk or Minefield).

Lorentz branch split off of 3.6.

Lorentz pulled some of the Electrolysis patches from Mozilla-Central.

Lorentz merged back into 3.6 (and was closed).

What is Lorentz? It is (was) a branch to contain merges of out of process plugins for Windows and Linux. Mac will follow, though maybe not on 3.6 branch. It will be included in an upcoming release of 3.6.

I’d just like to say, so that it’s on record, that I think pushing this as a minor update is a bad idea!

Keep up the good work though.

I know this is not the appropriate venue, but (sorry I can’t be bothered etc., plus I don’t have steps to reproduce) running Lorentz on Youtube I had one time I heard the video play, but did not see it. It was on a user profile page, after clicking in the videos list a couple times. Reloading the page fixed the issue.

Laurens, if you have a repeatable test-case, we’d love to hear about it, either here or preferably on bugzilla.mozilla.org.

thanks for the comments.

TBH I don’t get ff crashes so this will not be a great win for me (and that’s with 34 extensions).

Saying which it is a good idea and could be used to help with security at a later date.

The best news is that Mozilla are upping their game to compete with chrome and bringing out updates faster

Cheers.

Oh BTH I use FF for all browsing except one.

I have a large html file (9MB, 20k records in a table).

FF takes 30sec to open it, Chromium takes 5secs.

The filter on it uses js and is very fast in Chromium (10sec) but in FF > 5min
(tested with a new clean profile with no extensions).

Speed is what is letting you down but its still the best overall browser.

Thanks for all the hard work.

thanks for the comment, SilverWave.

I’d be interested to see your database file if it’s something you can share. Sounds like it might make a good JS benchmark.

In any case, I expect we’ll improve significantly in our next major release. Hopefully we’ll fix that single use case for you.

hmm its my ShelveLogger.html file for the last 5 years, I cant share that but I will look into creating a similar size test file, thanks for the interest

For the time being here is the link to the latest ShelveLogger version.

http://silverwav.wordpress.com/tag/version/

Then you just have to save 20465 web pages…

>Total Rows 20465 (Clips 2169, Default 18296).

…LOL

But being serious for a moment I will create some test data and get back to you.

Cheers.

that’s fantastic!

even if you could randomize that data (20465 entries of Lorem Ipsum? or does difference matter for sorting and filtering purposes) that could be incredible useful.

Thanks so much. I’ll file a bug to capture this.

filed bug 559396:
https://bugzilla.mozilla.org/show_bug.cgi?id=559396

Another thing to try is testing the same file in Firefox developer preview 3.7a4. We’ve made some solid perf improvements there and you might find it faster.

In any case, comment here or preferably, in the above-linked bug if you come up with some test data.

We really appreciate your help.

ps, developer preview available here:
http://www.mozilla.org/projects/devpreview/releasenotes/#download

OK I will do this formally later but for now here is a link to the Test Data I have created.

http://silverwav.wordpress.com/2010/04/14/firefox-speed-test/

Total Rows 20068 (Clips 6055, Default 14013).
12.6MB

I will do some testing and update with my times.

Cheers.

fantastic, thanks for the data! I can update the bug with these details and the link so we can get some profiler data started.

Test Results (Linux)

Firefox 3.6.4 ubuntu reload: 0:37 0:37 0:37
Chromium 5.0. ubuntu reload: 0.05 0:05 0:05

7.4 Slower

Firefox 3.6.4 ubuntu filter: 2:07 2:05
Chromium 5.0. ubuntu filter: 0:03 0:03

Filter word: Platypus

42.3 Slower
______________________________

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4pre) Gecko/20100410 Ubuntu/10.04 (lucid) Namoroka/3.6.4pre – Build ID: 20100410093139

Chromium 5.0.376.0 (44292) Ubuntu
______________________________

Lucid Beta 2 64bit
Linux version 2.6.32-20-generic (buildd@yellow) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #29-Ubuntu SMP Fri Apr 9 20:35:00 UTC 2010 (Ubuntu 2.6.32-20.29-generic 2.6.32.11+drm33.2)

CPU0: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping 07

8GB RAM
______________________________

Test Results – Win7

Firefox 3.6.3 win7 reload: 0:52 0:50 0:53
7.4 x Slower
Firefox 3.7.4 win7 reload: 1:02 0:56 0:54
8.1 x Slower
Chrome 5.0. win7 reload: 0.07 0:07 0:07

Firefox 3.6.4 win7 filter: 3:15 3:15
48.7 x Slower
Firefox 3.7.4 win7 filter: 0:33 0:34 0:34
8.5 x Slower
Chrome 5.0. win7 filter: 0:04 0:03 0:03

Machine
Windows 7 Prof 64Bit, 4GB RAM.
HP 550 Core 2 Duo Laptop

Results – Win7

Firefox 3.6.3 win7 reload: 0:52 0:50 0:53
7.4 x Slower
Firefox 3.7.4 win7 reload: 1:02 0:56 0:54
8.1 x Slower
Chrome 5.0. win7 reload: 0.07 0:07 0:07

Firefox 3.6.4 win7 filter: 3:15 3:15
48.7 x Slower
Firefox 3.7.4 win7 filter: 0:33 0:34 0:34
8.5 x Slower
Chrome 5.0. win7 filter: 0:04 0:03 0:03

Machine
Windows 7 Prof 64Bit, 4GB RAM.
HP 550 Core 2 Duo Laptop

OK happily there has been a large speed up in 3.7.a4 as regards to the filtering.

The filter operation in 3.7.a4 takes 6 times less than it did in 3.6.

It does not look as if the reload time has seen any improvement.

—
ps, please remove the text before “Results – Win7″ in the last post if possible (somehow a link crept in).
—

The improvements in 3.7.a4 are very encouraging but it makes you wonder what Google is doing to get such incredible sub 10sec times.

Luckily as it is open source someone can go have a look

hey, that’s good news. I’ll edit your reply as you asked and paste these comments into the bug.

again, thanks a bunch for taking the time to do this. I haven’t had a chance to play with your data file much, but did load it into 3.6. It’s definitely slow.