Performance/Status Meetings/2007-June-27: Difference between revisions

Line 51: Line 51:
== Gecko: Perf discussion ==
== Gecko: Perf discussion ==


* Perfathon next week
** vlad to provide profile data before meeting
* What's interesting data to collect?
** High priority: historical 1.8->1.9 Tp(1,2,3) numbers
* Tp vs Tp2
** How do we figure out if we can trust Tp2?
=== Last week ===


* jrpof tinderbox
* jrpof tinderbox
Line 84: Line 94:
** dbaron already maintains entrypoints into layout to assert that layout doesn't reenter incorrectly
** dbaron already maintains entrypoints into layout to assert that layout doesn't reenter incorrectly
** TODO: vlad/dbaron - connect with sun guys, take probe stuff somewhere
** TODO: vlad/dbaron - connect with sun guys, take probe stuff somewhere


== Other Information ==
== Other Information ==


Followup on JS timing granularity: turns out that it's not JS timing errors after all! Instead, it's the synthetic load I was using, which was to multiply a pair of numbers. If the load is changed to be addition of numbers, the measured time is a clean linear function of the number of additions. So the mystery becomes one of why multiplication in JS sometimes takes about 16ms longer than expected, but at least we're not suspicious about our measurement tools.
Followup on JS timing granularity: turns out that it's not JS timing errors after all! Instead, it's the synthetic load I was using, which was to multiply a pair of numbers. If the load is changed to be addition of numbers, the measured time is a clean linear function of the number of additions. So the mystery becomes one of why multiplication in JS sometimes takes about 16ms longer than expected, but at least we're not suspicious about our measurement tools.
Confirmed users, Bureaucrats and Sysops emeriti
792

edits