1313655, 1349924, 1355472, 1370196, 1374011, 1374934, 1376948, 1377339, 1382097, 1382650, 1384042, 1384562, 1385268, 1385282, 1388720, 1389159, 1398578, 1328140, 1339535, 1339758, 1341768, 1344469, 1346191, 1346217, 1346546, 1347489, 1356315, 1364854, 1364908, 1366263, 1368325, 1368626, 1369042, 1369762, 1370210, 1371593, 1372182, 1373195, 1373214, 1373290, 1373323, 1373615, 1374014, 1375505, 1376691, 1376799, 1376961, 1377238, 1377343, 1382973, 1383343, 1385953, 1386199, 1386555, 1386646, 1386685, 1386700, 1387018, 1388014, 1388354, 1388388, 1389510, 1391611, 1391639, 1392530, 1394365, 1395900, 1398140, 1422726
While looking at some benchmarks I'm evaluating Speedometer again. (not sure it is a very good benchmark, seems to focus on one particular case and testing how different frameworks deal with that, but we're quite slow with it anyhow). http://mozilla.pettay.fi/moztests/Speedometer.tar.bz2 is from https://github.com/WebKit/webkit/tree/master/PerformanceTests/Speedometer but I modified the InteractiveRunner.html to make profiling a bit easier. So, using InteractiveRunner.html, check EmberJS-TodoMVC and click run. In Zoom I see most of the time spent in JS, and that is also that Gecko profiler tells. Also BackboneJS-TodoMVC seems to spend most of the time in JS, and AngularJS-TodoMVC, and AngularJS-TodoMVC. And React-TodoMVC is based on Gecko profiler also largely JS. I see quite a bit IonBuilder calls there. Could someone more familiar with JS engine and JIT look at the test.
s/and AngularJS-TodoMVC, and AngularJS-TodoMVC/and AngularJS-TodoMVC/ (jQuery test has at least some parsing stuff showing up in the profile, and VanillaJS-TodoMVC, and also FlightJS-TodoMVC, although it is mostly JS, )
Could someone from JS team look at this. Recently I've seen JS to take lots of time in benchmarks which try to be realistic, like Speedometer. (Note, the test just tries that, but totally is not realistic.)
In profiles of these benchmarks I see the usual suspects: CrossCompartmentWrapper stuff, IC misses, and some non-trivial mprotect overhead when attaching Ion IC stubs. I've some serious IC redesign work planned for the coming weeks/months (starting with bug 1255352), hopefully that will make our ICs more robust and allow us to optimize more cases. Added this to my perf TODO list, clearing the needinfo for now.
jandem, any news on this?
(In reply to Olli Pettay [:smaug] from comment #4) > jandem, any news on this? Not yet. Right now I'm working on modernizing our exception handling and the JSContext/JSRuntime unification. I hope to continue working on CacheIR and other IC work soon though.
(Just CCing some folks from bug 1241091, there might be something in common here, given that Speedometer tests various JS frameworks)
Using Nightly 53 (20161217) on desktop this site stays in a loop. In Android Nightly it stalls and eventually pulls up "Warning: Unresponsive script.. Script: https://browserbench.org/Speedo...ower_components/react/react.js:7174"
At least EmberJS seems to spend some time in the interpreter and fun_apply.
platform-rel: --- → +
Whiteboard: [platform-rel-Frameworks][platform-rel-EmberJS] → [qf:meta][platform-rel-Frameworks][platform-rel-EmberJS]
Been regularly testing speed on 2008 model laptop running Arch Linux. * January on Browserbench 'Speedometer' I was maxing out at 10 runs per minute. * Test [on Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170515100238 CSet: e66dedabe582ba7b394aee4f89ed70fe389b3c46] is now running at 23.1 runs per minute. 131% speed improvement on the January test. Keep up the amazing work folks!
Further update since Fx55: Same machine - 2008 model laptop running Arch Linux. * January on Browserbench 'Speedometer' I was maxing out at 10 runs per minute. * Test 2 months ago [on Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170515100238 CSet: e66dedabe582ba7b394aee4f89ed70fe389b3c46] is now running at 23.1 runs per minute. * Test [on Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 ID:20170720100139 CSet: 0985725c848ec0cfc6f2f3c3a5aa3d71321e7620] is running at 27.9 runs per minute. Firefox Nightly is 279% faster on my machine than it was in January of this year.
I don't understand why I'm getting a 34 on the benchmark. My specs are high as seen below: i7 Quad 3770K @ 5Ghz ASUS P8Z77-V Deluxe Corsair 1050W PSU Corsair H100iV2 CPU Cooler Corsair 16GB RAM Sapphire Nitro R9 390 8GB DUAL ASUS PA249Q IPS 24" LCDs Samsung SSD 830, 840 256GB, 2TB Seagate Windows 10 Pro x64 (v1703) AMD Crimson 17.7.2 FIOS 1Gb/1Gb
After enabling my add-ons one by one and running the benchmark I came up with these number. No add-ons enabled resulted in a score of 97.1. 1. AutoplayStopper 0.9.8. This is the Webextensions version of Legacy FlashStopper. Lost ~ 12% 2. Zoom Page WE 5.1. Lost ~ 50% 3. UBlock Origin/webext 1.13.9b3. Lost ~ 28%. If I disable uBO only for the benchmark site I don't lose any points, I get a 97.1. I've contacted the developers of these three add-ons letting them know of these results.
(In reply to Gary [:streetwolf] from comment #12) > 3. UBlock Origin/webext 1.13.9b3. Lost ~ 28%. If I disable uBO only for the > benchmark site I don't lose any points, I get a 97.1. See bug 1339572 for example. Running benchmarks with extensions installed is usually not super useful unless if you're trying to study the details of the performance impacts of those extensions. We have some efforts ongoing about the improving the performance impact that having extensions like this installed can have over what happens inside web pages (which is part of the overhead you are seeing here) for example under bug 613498 but it's a lot of work and we need still more focus there.
You need to log in before you can comment on or make changes to this bug.