search

ProfBMoriarty / PS3.1

PS3.1 Repository
Other
3 stars 1 forks source link

_resetFader -> _copy is slow #19

Closed mdiehr closed 9 years ago

mdiehr commented 9 years ago

When initializing many PS instances on one page, Perlenspiel spends a lot of time initializing the faders. This is because _copy very slowly transfers properties between a settings object and the faders.

mdiehr commented 9 years ago

173.5 ms3.68 % 192.0 ms4.08 % ps.js:5959my._resetFader 76.3 ms1.62 % 0.1 ms0.00 % ps.js:5335my._copy 56.0 ms1.19 % 149.0 ms3.17 % ps.js:6655my._resetBead 0.2 ms0.00 % 0.3 ms0.01 % ps.js:680my._sys 0.1 ms0.00 % 0.1 ms0.00 % ps.js:5800my._checkColors

ProfBMoriarty commented 9 years ago

Could this be addressed by simply hardcoding the initialization?

Brian Moriarty IMGD Professor of Practice Worcester Polytechnic Institute 100 Institute Road, Worcester MA 01609 Email: bmoriarty@wpi.edumailto:bmoriarty@wpi.edu Web: users.wpi.edu/~bmoriarty Telephone: (508) 831-5638

From: Mark Diehr [mailto:notifications@github.com] Sent: Tuesday, December 16, 2014 4:51 PM To: ProfBMoriarty/PS3.1 Subject: Re: [PS3.1] _resetFader -> _copy is slow (#19)

3.5 ms3.68 % 192.0 ms4.08 % ps.js:5959my._resetFader

76.3 ms1.62 % 0.1 ms0.00 % ps.js:5335my._copy

56.0 ms1.19 % 149.0 ms3.17 % ps.js:6655my._resetBead 0.2 ms0.00 % 0.3 ms0.01 % ps.js:680my._sys

0.1 ms0.00 % 0.1 ms0.00 % ps.js:5800my._c

— Reply to this email directly or view it on GitHubhttps://github.com/ProfBMoriarty/PS3.1/issues/19#issuecomment-67238795.

mdiehr commented 9 years ago

I hope so! That was my first thought

mdiehr commented 9 years ago

Ok, changing it to a hard copy makes _resetFader run in about 1/4th the time. With 9 examples on one page: BEFORE: 289.0 ms AFTER: 82.7 ms

I tried something similar for _resetBead which was using 276.2 ms, and is now down to 44.1 ms

(All of these measurements are for Total, not Self)

mdiehr commented 9 years ago

The commit here fixes this issue: be1214ed65dd91a59f1e42574b03422a24a02abc

ProfBMoriarty commented 9 years ago

Interesting that a hardcoded copy is THAT much faster. Good thing to know!

I will update all such instances in my next build.

Brian Moriarty IMGD Professor of Practice Worcester Polytechnic Institute 100 Institute Road, Worcester MA 01609 Email: bmoriarty@wpi.edumailto:bmoriarty@wpi.edu Web: users.wpi.edu/~bmoriarty Telephone: (508) 831-5638

From: Mark Diehr [mailto:notifications@github.com] Sent: Tuesday, December 16, 2014 5:35 PM To: ProfBMoriarty/PS3.1 Cc: Moriarty, Brian J. Subject: Re: [PS3.1] _resetFader -> _copy is slow (#19)

Ok, changing it to a hard copy makes _resetFader run in about 1/4th the time. With 9 examples on one page: BEFORE: 289.0 ms AFTER: 82.7 ms

I tried something similar for _resetBead which was using 276.2 ms, and is now down to 44.1 ms

(All of these measurements are for Total, not Self)

— Reply to this email directly or view it on GitHubhttps://github.com/ProfBMoriarty/PS3.1/issues/19#issuecomment-67245765.

mdiehr commented 9 years ago

It has to do with how Chrome's JS compiler works - regular variable assignments translate nicely to regular compiled code, but dynamic functionality like _copy (which deeply inspects all known properties of an object) can't be optimized very well.

This is one of the downsides to JS that is tough to work around!

The _DEFAULTS object probably no longer needs bead or fader, now that I think about it - I will try removing them and seeing if it still works.