Question : prototypal definition of class attributes #490

Closed
webskin opened this Issue Oct 18, 2014 · 29 comments

Comments

Projects
None yet
4 participants
@webskin

webskin commented Oct 18, 2014

I think you choose to use this technique to gain memory space for all default attribute values.
But in certain cases it can degrade performance :
cf. http://codereview.stackexchange.com/a/28360

Do you think we can fall in this case ?

For instance, the Matrix2D class has these four properties : alpha, shadow, compositeOperation, visible which are only defined initially on the prototype scope. It is possible to have several definition of Matrix2D classes.

What do you think ?

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 21, 2014

Member

The answer there and the jsperf test provided are both a bit needlessly complex, but seem to point to that the summation is true. Seems like an unusual outcome, but I'm happy to do some testing and see if I can reproduce it. If so, I'll test it in place on Matrix2D, since it's such a performance sensitive class. If that provides a measurable improvement, I'll look at changing the whole library.

Would love to hear your results if you do any independent testing as well.

Member

gskinner commented Oct 21, 2014

The answer there and the jsperf test provided are both a bit needlessly complex, but seem to point to that the summation is true. Seems like an unusual outcome, but I'm happy to do some testing and see if I can reproduce it. If so, I'll test it in place on Matrix2D, since it's such a performance sensitive class. If that provides a measurable improvement, I'll look at changing the whole library.

Would love to hear your results if you do any independent testing as well.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 21, 2014

Member

So, some quick initial results:
I wrote a little test with our new perfFramework, that instantiates Matrix2D objects, then assigns values to the instances randomly:

var props = i%16;
if (props&1) { mtx.compositeOperation = "foo"; }
if (props&2) { mtx.alpha = Math.random(); }
if (props&4) { mtx.shadow = {}; }
if (props&8) { mtx.visible = false; }

Supposedly, that should create 16 different object "types".

I then ran the test against all of the current versions of the library, including NEXT, and confirmed that NEXT runs at essentially the same speed as 0.7.1. With that as a baseline, I modified the Matrix2D class to remove the prototype declarations for the properties above, and move them into the initialize method instead. This should ensure there is only one "type", because all props are defined on every instance in the same order.

I tested again, and saw no change whatsoever in performance. So, thus far, it looks like this may be a non-issue. I would definitely encourage you to validate my tests and results. The test is "extras/PerformanceTest/matrix.html".
https://github.com/CreateJS/EaselJS/tree/master/extras/PerformanceTests

Try running the test with report and auto params, to test each version of the library 5 times and compare the results:
matrix.html?report=table&auto=5

Interestingly, this test IS showing a noticeable increase in the cost to set property values between 0.6.1 and 0.7.0, which I've noticed in other tests. For example, a large portion of the change in the sprite test is attributable to a single property set. Very odd, and warrants more exploration, because I'm really not sure what could have changed to make individual instance properties more expensive to manipulate.

Member

gskinner commented Oct 21, 2014

So, some quick initial results:
I wrote a little test with our new perfFramework, that instantiates Matrix2D objects, then assigns values to the instances randomly:

var props = i%16;
if (props&1) { mtx.compositeOperation = "foo"; }
if (props&2) { mtx.alpha = Math.random(); }
if (props&4) { mtx.shadow = {}; }
if (props&8) { mtx.visible = false; }

Supposedly, that should create 16 different object "types".

I then ran the test against all of the current versions of the library, including NEXT, and confirmed that NEXT runs at essentially the same speed as 0.7.1. With that as a baseline, I modified the Matrix2D class to remove the prototype declarations for the properties above, and move them into the initialize method instead. This should ensure there is only one "type", because all props are defined on every instance in the same order.

I tested again, and saw no change whatsoever in performance. So, thus far, it looks like this may be a non-issue. I would definitely encourage you to validate my tests and results. The test is "extras/PerformanceTest/matrix.html".
https://github.com/CreateJS/EaselJS/tree/master/extras/PerformanceTests

Try running the test with report and auto params, to test each version of the library 5 times and compare the results:
matrix.html?report=table&auto=5

Interestingly, this test IS showing a noticeable increase in the cost to set property values between 0.6.1 and 0.7.0, which I've noticed in other tests. For example, a large portion of the change in the sprite test is attributable to a single property set. Very odd, and warrants more exploration, because I'm really not sure what could have changed to make individual instance properties more expensive to manipulate.

@gskinner gskinner added the UTR label Oct 21, 2014

@webskin

This comment has been minimized.

Show comment
Hide comment
@webskin

webskin Oct 21, 2014

Thank you for the test.

Here are my results :

perf

I will do more tests soon.

webskin commented Oct 21, 2014

Thank you for the test.

Here are my results :

perf

I will do more tests soon.

@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 21, 2014

Contributor

So I played around with and there's definitely an improvement when I initialize everything in the initialize function.

First thing to note is that your test is invoking a method on the "different object types" rather than passing in the object as a parameter like the stackoverflow example. I add in an mtx.append(otherMtx) to test this form too.

I found there to be quite a bit of variance in test runs. Variance is to be expected but there was a little more than I thought there was going to be. I also hit an issue where occasionally the first few versions would have very high instantiate values for no obvious reason. I simply reran the test when this happened.

Generally in runs 2-7 it seems that if you initialize the four properties then the instantiate takes 1.5x-2x longer (but is the fastest section by a long shot), setting the properties takes 2x-3x longer and the calculate section is somewhat faster, depending on the calculations. It seems the overall time is generally either on a par or better than 0.7.1 after making this change.

As a final couple of tests, I altered the setup of Matrix2d so that it could accept all the parameters on object creation instead of altering the properties afterwards. This gets rid of the props section altogether. I didn't record the results, but they were very similar the final test where I left the properties out of the constructor, but set them in the initialization loop rather than in a separate props loop (ie the object is 'fresh'). This seems to totally get rid of the slower instantiate+props speed, with the new instantiate loop running even faster on NEXT than the previous versions. I think this test does demonstrate one of the issues with synthetic benchmarks though.

Run 1

NEXT built from github master - no code altered
version instantiate props   calculate   total
NEXT    17.3ms  37.0ms  282.8ms 337.3ms
0.7.1   14.5ms  32.6ms  263.1ms 310.3ms
0.7.0   19.3ms  30.3ms  266.9ms 316.7ms
0.6.1   26.2ms  15.0ms  258.5ms 299.8ms
0.6.0   24.7ms  13.1ms  285.5ms 323.4ms
0.5.0   14.9ms  20.1ms  285.7ms 320.8ms
0.4.2   15.5ms  16.7ms  288.1ms 320.4ms
0.4.1   15.4ms  19.8ms  287.8ms 323.1ms 

Run 2

NEXT Matrix2d.js altered to instantiate properties in initialize function
NEXT    22.3ms  106.5ms 187.6ms 316.5ms
0.7.1   15.2ms  34.5ms  288.5ms 338.3ms

Run 3

NEXT Matrix2d.js reverted to master
matrix.html calculate test altered to only loop to l-1 and include mtx.append(arr[i+1]);
version instantiate props   calculate   total
NEXT    14.4ms  32.4ms  673.5ms 720.5ms
0.7.1   15.6ms  29.2ms  653.9ms 698.8ms
0.7.0   17.2ms  31.1ms  648.8ms 697.3ms
0.6.1   13.8ms  19.9ms  521.7ms 555.5ms
0.6.0   17.0ms  26.5ms  606.4ms 650.0ms
0.5.0   13.4ms  21.7ms  502.4ms 537.7ms
0.4.2   15.3ms  11.9ms  495.8ms 523.2ms
0.4.1   15.0ms  8.7ms   511.9ms 535.8ms 

Run 4

Matrix2d.js altered to instantiate properties in initialize function
matrix.html calculate test altered to only loop to l-1 and include mtx.append(arr[i+1]);
version instantiate props   calculate   total
NEXT    24.7ms  104.9ms 452.7ms 582.5ms
0.7.1   14.5ms  30.8ms  651.6ms 697.2ms

Run 5

NEXT Matrix2D.js reverted to master
matrix.html calculate test altered to only loop to l-1 and only has mtx.append(arr[i+1]); (no appendTransform or appendProperties)
version instantiate props   calculate   total
NEXT    18.8ms  34.9ms  484.2ms 538.0ms
0.7.1   16.0ms  33.1ms  468.5ms 517.7ms
0.7.0   14.0ms  33.4ms  468.3ms 515.8ms
0.6.1   14.5ms  23.4ms  343.2ms 381.2ms
0.6.0   12.8ms  24.9ms  338.2ms 375.9ms
0.5.0   15.8ms  24.0ms  341.9ms 381.7ms
0.4.2   16.6ms  23.3ms  337.0ms 377.1ms
0.4.1   15.7ms  23.3ms  335.2ms 374.4ms 

Run 6

NEXT Matrix2d altered to instantiate properties in initialize function
matrix.html calculate test altered to only loop to l-1 and only has mtx.append(arr[i+1]); (no appendTransform or appendProperties)
version instantiate props   calculate   total
NEXT    21.4ms  108.2ms 389.7ms 519.4ms
0.7.1   13.9ms  33.6ms  460.5ms 508.2ms
0.7.0   15.2ms  32.7ms  465.8ms 513.9ms
0.6.1   13.0ms  23.4ms  343.2ms 379.7ms
0.6.0   14.8ms  23.3ms  338.9ms 377.2ms
0.5.0   14.5ms  23.6ms  334.4ms 372.7ms
0.4.2   15.3ms  22.9ms  334.1ms 372.5ms
0.4.1   14.5ms  23.7ms  351.5ms 389.9ms

Run 7

NEXT Matrix2d altered to instantiate properties in initialize function
matrix.html calculate test altered to only loop from 1 and only has mtx.append(arr[i-1]); (no appendTransform or appendProperties)
Note these test results are upside down compared to the others
0.4.1   16.6ms  20.8ms  495.9ms 533.6ms
0.4.2   18.5ms  26.5ms  499.4ms 544.6ms
0.5.0   15.6ms  29.5ms  478.0ms 523.3ms
0.6.0   12.8ms  22.3ms  479.6ms 514.9ms
0.6.1   14.1ms  28.7ms  478.7ms 521.7ms
0.7.0   15.3ms  31.4ms  469.7ms 516.6ms
0.7.1   15.4ms  29.4ms  484.9ms 529.8ms
NEXT    26.4ms  106.8ms 351.7ms 485.1ms 

Run 8

NEXT Matrix2d altered to instantiate properties in initialize function
matrix.html instantiate test altered to add random properties
matrix.html props loop removed
matrix.html calculate test altered to only loop from 1 and has mtx.append(arr[i-1]) added
version instantiate calculate   total
NEXT    34.0ms  411.0ms 445.1ms
0.7.1   42.9ms  606.2ms 649.2ms
0.7.0   40.7ms  622.0ms 662.8ms
0.6.1   32.2ms  661.3ms 693.6ms
0.6.0   32.8ms  668.7ms 701.6ms
0.5.0   33.1ms  653.8ms 686.9ms
0.4.2   31.1ms  656.4ms 687.6ms
0.4.1   33.8ms  677.5ms 711.4ms 
Contributor

MannyC commented Oct 21, 2014

So I played around with and there's definitely an improvement when I initialize everything in the initialize function.

First thing to note is that your test is invoking a method on the "different object types" rather than passing in the object as a parameter like the stackoverflow example. I add in an mtx.append(otherMtx) to test this form too.

I found there to be quite a bit of variance in test runs. Variance is to be expected but there was a little more than I thought there was going to be. I also hit an issue where occasionally the first few versions would have very high instantiate values for no obvious reason. I simply reran the test when this happened.

Generally in runs 2-7 it seems that if you initialize the four properties then the instantiate takes 1.5x-2x longer (but is the fastest section by a long shot), setting the properties takes 2x-3x longer and the calculate section is somewhat faster, depending on the calculations. It seems the overall time is generally either on a par or better than 0.7.1 after making this change.

As a final couple of tests, I altered the setup of Matrix2d so that it could accept all the parameters on object creation instead of altering the properties afterwards. This gets rid of the props section altogether. I didn't record the results, but they were very similar the final test where I left the properties out of the constructor, but set them in the initialization loop rather than in a separate props loop (ie the object is 'fresh'). This seems to totally get rid of the slower instantiate+props speed, with the new instantiate loop running even faster on NEXT than the previous versions. I think this test does demonstrate one of the issues with synthetic benchmarks though.

Run 1

NEXT built from github master - no code altered
version instantiate props   calculate   total
NEXT    17.3ms  37.0ms  282.8ms 337.3ms
0.7.1   14.5ms  32.6ms  263.1ms 310.3ms
0.7.0   19.3ms  30.3ms  266.9ms 316.7ms
0.6.1   26.2ms  15.0ms  258.5ms 299.8ms
0.6.0   24.7ms  13.1ms  285.5ms 323.4ms
0.5.0   14.9ms  20.1ms  285.7ms 320.8ms
0.4.2   15.5ms  16.7ms  288.1ms 320.4ms
0.4.1   15.4ms  19.8ms  287.8ms 323.1ms 

Run 2

NEXT Matrix2d.js altered to instantiate properties in initialize function
NEXT    22.3ms  106.5ms 187.6ms 316.5ms
0.7.1   15.2ms  34.5ms  288.5ms 338.3ms

Run 3

NEXT Matrix2d.js reverted to master
matrix.html calculate test altered to only loop to l-1 and include mtx.append(arr[i+1]);
version instantiate props   calculate   total
NEXT    14.4ms  32.4ms  673.5ms 720.5ms
0.7.1   15.6ms  29.2ms  653.9ms 698.8ms
0.7.0   17.2ms  31.1ms  648.8ms 697.3ms
0.6.1   13.8ms  19.9ms  521.7ms 555.5ms
0.6.0   17.0ms  26.5ms  606.4ms 650.0ms
0.5.0   13.4ms  21.7ms  502.4ms 537.7ms
0.4.2   15.3ms  11.9ms  495.8ms 523.2ms
0.4.1   15.0ms  8.7ms   511.9ms 535.8ms 

Run 4

Matrix2d.js altered to instantiate properties in initialize function
matrix.html calculate test altered to only loop to l-1 and include mtx.append(arr[i+1]);
version instantiate props   calculate   total
NEXT    24.7ms  104.9ms 452.7ms 582.5ms
0.7.1   14.5ms  30.8ms  651.6ms 697.2ms

Run 5

NEXT Matrix2D.js reverted to master
matrix.html calculate test altered to only loop to l-1 and only has mtx.append(arr[i+1]); (no appendTransform or appendProperties)
version instantiate props   calculate   total
NEXT    18.8ms  34.9ms  484.2ms 538.0ms
0.7.1   16.0ms  33.1ms  468.5ms 517.7ms
0.7.0   14.0ms  33.4ms  468.3ms 515.8ms
0.6.1   14.5ms  23.4ms  343.2ms 381.2ms
0.6.0   12.8ms  24.9ms  338.2ms 375.9ms
0.5.0   15.8ms  24.0ms  341.9ms 381.7ms
0.4.2   16.6ms  23.3ms  337.0ms 377.1ms
0.4.1   15.7ms  23.3ms  335.2ms 374.4ms 

Run 6

NEXT Matrix2d altered to instantiate properties in initialize function
matrix.html calculate test altered to only loop to l-1 and only has mtx.append(arr[i+1]); (no appendTransform or appendProperties)
version instantiate props   calculate   total
NEXT    21.4ms  108.2ms 389.7ms 519.4ms
0.7.1   13.9ms  33.6ms  460.5ms 508.2ms
0.7.0   15.2ms  32.7ms  465.8ms 513.9ms
0.6.1   13.0ms  23.4ms  343.2ms 379.7ms
0.6.0   14.8ms  23.3ms  338.9ms 377.2ms
0.5.0   14.5ms  23.6ms  334.4ms 372.7ms
0.4.2   15.3ms  22.9ms  334.1ms 372.5ms
0.4.1   14.5ms  23.7ms  351.5ms 389.9ms

Run 7

NEXT Matrix2d altered to instantiate properties in initialize function
matrix.html calculate test altered to only loop from 1 and only has mtx.append(arr[i-1]); (no appendTransform or appendProperties)
Note these test results are upside down compared to the others
0.4.1   16.6ms  20.8ms  495.9ms 533.6ms
0.4.2   18.5ms  26.5ms  499.4ms 544.6ms
0.5.0   15.6ms  29.5ms  478.0ms 523.3ms
0.6.0   12.8ms  22.3ms  479.6ms 514.9ms
0.6.1   14.1ms  28.7ms  478.7ms 521.7ms
0.7.0   15.3ms  31.4ms  469.7ms 516.6ms
0.7.1   15.4ms  29.4ms  484.9ms 529.8ms
NEXT    26.4ms  106.8ms 351.7ms 485.1ms 

Run 8

NEXT Matrix2d altered to instantiate properties in initialize function
matrix.html instantiate test altered to add random properties
matrix.html props loop removed
matrix.html calculate test altered to only loop from 1 and has mtx.append(arr[i-1]) added
version instantiate calculate   total
NEXT    34.0ms  411.0ms 445.1ms
0.7.1   42.9ms  606.2ms 649.2ms
0.7.0   40.7ms  622.0ms 662.8ms
0.6.1   32.2ms  661.3ms 693.6ms
0.6.0   32.8ms  668.7ms 701.6ms
0.5.0   33.1ms  653.8ms 686.9ms
0.4.2   31.1ms  656.4ms 687.6ms
0.4.1   33.8ms  677.5ms 711.4ms 
@webskin

This comment has been minimized.

Show comment
Hide comment
@webskin

webskin Oct 21, 2014

Right @MannyC

Megamorphism is present when the Matrix2D is passed into the function as parameter.

is your Run 8 on your master branch ?

webskin commented Oct 21, 2014

Right @MannyC

Megamorphism is present when the Matrix2D is passed into the function as parameter.

is your Run 8 on your master branch ?

@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 21, 2014

Contributor

@webskin that has the instantiated properties, and the test updated to include .append() and also create the "different" properties in the instantiate loop.

All previous benchmarks were Chrome 38.0.2125.104 (64-bit) on Linux.
Interestingly Firefox 33.0 on Linux is giving totally different results:

version instantiate calculate   total
NEXT    14.1ms  248.6ms 262.9ms
0.7.1   16.7ms  271.9ms 288.8ms
0.7.0   19.2ms  264.7ms 284.0ms
0.6.1   42.6ms  551.1ms 593.9ms
0.6.0   44.6ms  544.1ms 588.8ms
0.5.0   47.2ms  524.2ms 571.5ms
0.4.2   45.9ms  512.5ms 558.6ms
0.4.1   47.6ms  560.4ms 608.1ms"

Much less/no improvement due to this "optimization" but a general trend towards it being faster as the versions get newer, the opposite of how things were going with Chrome.

Contributor

MannyC commented Oct 21, 2014

@webskin that has the instantiated properties, and the test updated to include .append() and also create the "different" properties in the instantiate loop.

All previous benchmarks were Chrome 38.0.2125.104 (64-bit) on Linux.
Interestingly Firefox 33.0 on Linux is giving totally different results:

version instantiate calculate   total
NEXT    14.1ms  248.6ms 262.9ms
0.7.1   16.7ms  271.9ms 288.8ms
0.7.0   19.2ms  264.7ms 284.0ms
0.6.1   42.6ms  551.1ms 593.9ms
0.6.0   44.6ms  544.1ms 588.8ms
0.5.0   47.2ms  524.2ms 571.5ms
0.4.2   45.9ms  512.5ms 558.6ms
0.4.1   47.6ms  560.4ms 608.1ms"

Much less/no improvement due to this "optimization" but a general trend towards it being faster as the versions get newer, the opposite of how things were going with Chrome.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 22, 2014

Member

Thanks again to everyone for the ongoing feedback and testing!

I did another round of testing. The only thing I changed was to focus the "calculate" part of the test on passing Matrix2D as a param. Note: I'm using appendMatrix(), which expects a matrix as a param - I'm fairly sure your test is generating NaN results.

for (var i=0; i<l; i+=2) {
    var mtx0 = arr[i], mtx1 = arr[i+1];
    mtx0.appendMatrix(mtx1);
    mtx1.appendMatrix(mtx0);
}

Unfortunately, I'm actually seeing a consistent decrease in performance when comparing NEXT with instance definitions versus 0.7.1 with prototype definitions. The following results were on Chrome 38 OSX, using 10 iterations to try to get a nice stable read.

version instantiate props   calculate   total
NEXT    20.5ms  38.2ms  108.6ms 167.5ms
0.7.1   14.5ms  37.4ms  71.7ms  123.7ms
0.6.1   22.1ms  22.4ms  91.5ms  136.2ms
0.4.1   15.0ms  20.8ms  80.5ms  116.4ms 

Firefox results for me are similar to what you saw, a general trend towards better performance, but with no significant change between NEXT and 0.7.1.

I'm still hopeful there is an optimization to be found here. It's always fantastic when we can release a new version with a significant performance improvement!

Member

gskinner commented Oct 22, 2014

Thanks again to everyone for the ongoing feedback and testing!

I did another round of testing. The only thing I changed was to focus the "calculate" part of the test on passing Matrix2D as a param. Note: I'm using appendMatrix(), which expects a matrix as a param - I'm fairly sure your test is generating NaN results.

for (var i=0; i<l; i+=2) {
    var mtx0 = arr[i], mtx1 = arr[i+1];
    mtx0.appendMatrix(mtx1);
    mtx1.appendMatrix(mtx0);
}

Unfortunately, I'm actually seeing a consistent decrease in performance when comparing NEXT with instance definitions versus 0.7.1 with prototype definitions. The following results were on Chrome 38 OSX, using 10 iterations to try to get a nice stable read.

version instantiate props   calculate   total
NEXT    20.5ms  38.2ms  108.6ms 167.5ms
0.7.1   14.5ms  37.4ms  71.7ms  123.7ms
0.6.1   22.1ms  22.4ms  91.5ms  136.2ms
0.4.1   15.0ms  20.8ms  80.5ms  116.4ms 

Firefox results for me are similar to what you saw, a general trend towards better performance, but with no significant change between NEXT and 0.7.1.

I'm still hopeful there is an optimization to be found here. It's always fantastic when we can release a new version with a significant performance improvement!

@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 22, 2014

Contributor

Note: I'm using appendMatrix(), which expects a matrix as a param - I'm fairly sure your test is generating NaN results.

Looks like you're correct, and I'm pretty sure I checked for that at some stage so I must have changed it since then. I was going to mention earlier that we should really have some sort of checksum at the end to make sure that the "optimizations" are valid. I'll try your version.

Contributor

MannyC commented Oct 22, 2014

Note: I'm using appendMatrix(), which expects a matrix as a param - I'm fairly sure your test is generating NaN results.

Looks like you're correct, and I'm pretty sure I checked for that at some stage so I must have changed it since then. I was going to mention earlier that we should really have some sort of checksum at the end to make sure that the "optimizations" are valid. I'll try your version.

@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 22, 2014

Contributor

Okay, so I'm seeing even more of a speed up now.

version instantiate calculate   total
NEXT    31.9ms  8.1ms   40.2ms
0.7.1   35.1ms  81.1ms  116.4ms
0.7.0   35.3ms  76.5ms  112.0ms
0.6.1   31.0ms  111.0ms 142.1ms
0.6.0   28.1ms  83.2ms  111.3ms
0.5.0   29.7ms  100.1ms 129.8ms
0.4.2   28.3ms  84.5ms  113.0ms
0.4.1   29.5ms  95.1ms  124.7ms 

It isn't so clear with the original instantiate loop followed by a props loop.

version instantiate props   calculate   total
NEXT    29.1ms  122.1ms 13.1ms  164.5ms
0.7.1   22.0ms  43.1ms  92.2ms  157.4ms
0.7.0   23.8ms  43.1ms  99.1ms  166.2ms
0.6.1   24.8ms  17.8ms  97.9ms  140.6ms
0.6.0   13.7ms  23.2ms  86.6ms  123.6ms
0.5.0   16.1ms  23.0ms  88.5ms  127.7ms
0.4.2   15.0ms  9.0ms   98.9ms  123.0ms
0.4.1   15.6ms  10.4ms  112.2ms 138.4ms

However, note the shift of the time from calculate in the previous versions to props in the NEXT version. Are you sure that you rebuilt the NEXT library with all props initialized in your last run, because if so it's interesting that we're getting such wildly different results (your results don't exhibit this change towards the time being spent in props).

Even Firefox has changed its tune

version instantiate props   calculate   total
NEXT    81.8ms  27.6ms  70.8ms  180.3ms
0.7.1   79.8ms  34.9ms  314.7ms 429.5ms
0.7.0   88.9ms  39.3ms  315.6ms 443.9ms
0.6.1   76.6ms  59.1ms  342.7ms 478.6ms
0.6.0   91.5ms  73.3ms  410.3ms 575.3ms
0.5.0   82.2ms  63.2ms  365.0ms 510.5ms
0.4.2   113.4ms 62.7ms  334.1ms 510.2ms
0.4.1   109.1ms 59.1ms  362.8ms 531.2ms
Contributor

MannyC commented Oct 22, 2014

Okay, so I'm seeing even more of a speed up now.

version instantiate calculate   total
NEXT    31.9ms  8.1ms   40.2ms
0.7.1   35.1ms  81.1ms  116.4ms
0.7.0   35.3ms  76.5ms  112.0ms
0.6.1   31.0ms  111.0ms 142.1ms
0.6.0   28.1ms  83.2ms  111.3ms
0.5.0   29.7ms  100.1ms 129.8ms
0.4.2   28.3ms  84.5ms  113.0ms
0.4.1   29.5ms  95.1ms  124.7ms 

It isn't so clear with the original instantiate loop followed by a props loop.

version instantiate props   calculate   total
NEXT    29.1ms  122.1ms 13.1ms  164.5ms
0.7.1   22.0ms  43.1ms  92.2ms  157.4ms
0.7.0   23.8ms  43.1ms  99.1ms  166.2ms
0.6.1   24.8ms  17.8ms  97.9ms  140.6ms
0.6.0   13.7ms  23.2ms  86.6ms  123.6ms
0.5.0   16.1ms  23.0ms  88.5ms  127.7ms
0.4.2   15.0ms  9.0ms   98.9ms  123.0ms
0.4.1   15.6ms  10.4ms  112.2ms 138.4ms

However, note the shift of the time from calculate in the previous versions to props in the NEXT version. Are you sure that you rebuilt the NEXT library with all props initialized in your last run, because if so it's interesting that we're getting such wildly different results (your results don't exhibit this change towards the time being spent in props).

Even Firefox has changed its tune

version instantiate props   calculate   total
NEXT    81.8ms  27.6ms  70.8ms  180.3ms
0.7.1   79.8ms  34.9ms  314.7ms 429.5ms
0.7.0   88.9ms  39.3ms  315.6ms 443.9ms
0.6.1   76.6ms  59.1ms  342.7ms 478.6ms
0.6.0   91.5ms  73.3ms  410.3ms 575.3ms
0.5.0   82.2ms  63.2ms  365.0ms 510.5ms
0.4.2   113.4ms 62.7ms  334.1ms 510.2ms
0.4.1   109.1ms 59.1ms  362.8ms 531.2ms
@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 22, 2014

Contributor

IE 11.0 on W7, combined instantiate and props.

version instantiate calculate   total
NEXT    128.0ms 67.8ms  195.9ms
0.7.1   133.1ms 192.0ms 325.1ms
0.7.0   136.1ms 227.0ms 363.2ms
0.6.1   146.9ms 314.7ms 461.6ms
0.6.0   146.3ms 279.1ms 425.5ms
0.5.0   147.6ms 282.3ms 430.0ms
0.4.2   161.7ms 292.1ms 453.9ms
0.4.1   164.1ms 313.9ms 478.1ms
Contributor

MannyC commented Oct 22, 2014

IE 11.0 on W7, combined instantiate and props.

version instantiate calculate   total
NEXT    128.0ms 67.8ms  195.9ms
0.7.1   133.1ms 192.0ms 325.1ms
0.7.0   136.1ms 227.0ms 363.2ms
0.6.1   146.9ms 314.7ms 461.6ms
0.6.0   146.3ms 279.1ms 425.5ms
0.5.0   147.6ms 282.3ms 430.0ms
0.4.2   161.7ms 292.1ms 453.9ms
0.4.1   164.1ms 313.9ms 478.1ms
@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 22, 2014

Member

Yes. I'm certain I'm testing against the correct version. I even went so far as to inspect the lib in-browser to make sure. My only changes to the Matrix2D class are commenting out all of the prototype property definitions, and defining them in initialize instead.

Here's my versions of the relevant files:
https://gist.github.com/gskinner/1dfb0d274c2fd3aa5ede

I'm seeing a consistent slowdown of around 10-20% using the test described above. Chrome 38 OSX.

version instantiate props   calculate   total
NEXT    16.6ms  33.9ms  82.1ms  132.8ms
0.7.1   15.3ms  32.2ms  60.7ms  108.4ms
0.6.1   25.4ms  9.7ms   80.8ms  116.0ms
0.4.1   19.1ms  18.3ms  77.1ms  114.7ms 
Member

gskinner commented Oct 22, 2014

Yes. I'm certain I'm testing against the correct version. I even went so far as to inspect the lib in-browser to make sure. My only changes to the Matrix2D class are commenting out all of the prototype property definitions, and defining them in initialize instead.

Here's my versions of the relevant files:
https://gist.github.com/gskinner/1dfb0d274c2fd3aa5ede

I'm seeing a consistent slowdown of around 10-20% using the test described above. Chrome 38 OSX.

version instantiate props   calculate   total
NEXT    16.6ms  33.9ms  82.1ms  132.8ms
0.7.1   15.3ms  32.2ms  60.7ms  108.4ms
0.6.1   25.4ms  9.7ms   80.8ms  116.0ms
0.4.1   19.1ms  18.3ms  77.1ms  114.7ms 
@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 22, 2014

Contributor

Ah, there it is, you're actually setting the props on the prototype during the initialize method rather than on the object being created.

Contributor

MannyC commented Oct 22, 2014

Ah, there it is, you're actually setting the props on the prototype during the initialize method rather than on the object being created.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 22, 2014

Member

Gah! Head smack! Will test again now!

Member

gskinner commented Oct 22, 2014

Gah! Head smack! Will test again now!

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 22, 2014

Member

Revised and tested again. Definitely got different results this time. I see a huge shift of time from calculate to props, but overall it's even slower than before (25-50%). Interesting, and warrants some more exploration.

version instantiate props   calculate   total
NEXT    19.2ms  125.6ms 15.6ms  160.5ms
0.7.1   15.8ms  32.2ms  60.7ms  108.9ms
0.6.1   16.1ms  13.5ms  82.9ms  112.6ms
0.4.1   15.3ms  20.0ms  79.2ms  114.6ms 
Member

gskinner commented Oct 22, 2014

Revised and tested again. Definitely got different results this time. I see a huge shift of time from calculate to props, but overall it's even slower than before (25-50%). Interesting, and warrants some more exploration.

version instantiate props   calculate   total
NEXT    19.2ms  125.6ms 15.6ms  160.5ms
0.7.1   15.8ms  32.2ms  60.7ms  108.9ms
0.6.1   16.1ms  13.5ms  82.9ms  112.6ms
0.4.1   15.3ms  20.0ms  79.2ms  114.6ms 
@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 22, 2014

Member

So, to summarize the findings so far:

  1. If we define properties on the prototype, then it can lead to the type fragmenting, which prevents methods that operate on that type from being fully optimized (aka Megamorphism).
  2. However, if we define our properties on the instance, for some reason it results in a huge increase in the cost to assign new values to that property.

Does that sound right? If so, it really comes down to solving # 2. If we can figure out a way to eliminate that cost, this could provide a huge performance benefit throughout the library.

I'm going to test whether its just the initial property assignment that's different, or all subsequent ones by duplicating the "props" loop.

Member

gskinner commented Oct 22, 2014

So, to summarize the findings so far:

  1. If we define properties on the prototype, then it can lead to the type fragmenting, which prevents methods that operate on that type from being fully optimized (aka Megamorphism).
  2. However, if we define our properties on the instance, for some reason it results in a huge increase in the cost to assign new values to that property.

Does that sound right? If so, it really comes down to solving # 2. If we can figure out a way to eliminate that cost, this could provide a huge performance benefit throughout the library.

I'm going to test whether its just the initial property assignment that's different, or all subsequent ones by duplicating the "props" loop.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 22, 2014

Member

Confirmed. For whatever reason, it looks like it's just the first change to the instance property that is very expensive. Subsequent changes are much faster when using the instance definitions.

version instantiate props1  props2  calculate   total
NEXT    25.4ms  127.8ms 10.7ms  17.4ms  181.4ms
0.7.1   16.4ms  35.1ms  27.4ms  73.7ms  152.7ms
0.6.1   26.7ms  26.6ms  24.9ms  110.1ms 188.5ms
0.4.1   21.1ms  13.0ms  24.9ms  92.2ms  151.4ms 

It's bizarre, because the first assignment (in initialize) is very cheap, the second (props1) is VERY expensive, and then subsequent assignments are cheap (props2).

Perhaps on the second assignment (props1), the VM evaluates the old and new values and tries to determine a type? Total guess at this point.

Member

gskinner commented Oct 22, 2014

Confirmed. For whatever reason, it looks like it's just the first change to the instance property that is very expensive. Subsequent changes are much faster when using the instance definitions.

version instantiate props1  props2  calculate   total
NEXT    25.4ms  127.8ms 10.7ms  17.4ms  181.4ms
0.7.1   16.4ms  35.1ms  27.4ms  73.7ms  152.7ms
0.6.1   26.7ms  26.6ms  24.9ms  110.1ms 188.5ms
0.4.1   21.1ms  13.0ms  24.9ms  92.2ms  151.4ms 

It's bizarre, because the first assignment (in initialize) is very cheap, the second (props1) is VERY expensive, and then subsequent assignments are cheap (props2).

Perhaps on the second assignment (props1), the VM evaluates the old and new values and tries to determine a type? Total guess at this point.

@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 22, 2014

Contributor

Agreed on the findings, and the aim being to solve # 2.

To build on your last observation (that the second "external" props setting is very cheap), I changed it to do the first external props setting as part of the initialization loop (not in the initialize method, in matrix.html). This is very cheap. I then put in a couple of props loops and all subsequent property assignments are also cheap, and the overall time is much less than if I omit the initialization loop assignment altogether.

Contributor

MannyC commented Oct 22, 2014

Agreed on the findings, and the aim being to solve # 2.

To build on your last observation (that the second "external" props setting is very cheap), I changed it to do the first external props setting as part of the initialization loop (not in the initialize method, in matrix.html). This is very cheap. I then put in a couple of props loops and all subsequent property assignments are also cheap, and the overall time is much less than if I omit the initialization loop assignment altogether.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 22, 2014

Member

Ha. I did the same test. At least we're thinking along the same lines.

Added an initProps loop to set all of the initial property value externally. It still takes significantly longer than subsequent assignments (~7x), but seems to be the fastest option so far (vs 15x) . The question is why this takes so much longer if we do assignments in initialize and how we get similar results in a format that's actually portable.

version instantiate initProps   props1  props2  calculate   total
NEXT    17.9ms  152.0ms 23.0ms  9.0ms   10.0ms  212.0ms
0.7.1   15.8ms  69.7ms  9.3ms   22.9ms  9.3ms   127.1ms

The above has property definitions in NEXT, and of course prototype definitions in 0.7.1. Interestingly that increase in props2 for 0.7.1 is consistent. First (full) assignment is very slow, the second is really fast, the third is slow, and then its back to fast.

Member

gskinner commented Oct 22, 2014

Ha. I did the same test. At least we're thinking along the same lines.

Added an initProps loop to set all of the initial property value externally. It still takes significantly longer than subsequent assignments (~7x), but seems to be the fastest option so far (vs 15x) . The question is why this takes so much longer if we do assignments in initialize and how we get similar results in a format that's actually portable.

version instantiate initProps   props1  props2  calculate   total
NEXT    17.9ms  152.0ms 23.0ms  9.0ms   10.0ms  212.0ms
0.7.1   15.8ms  69.7ms  9.3ms   22.9ms  9.3ms   127.1ms

The above has property definitions in NEXT, and of course prototype definitions in 0.7.1. Interestingly that increase in props2 for 0.7.1 is consistent. First (full) assignment is very slow, the second is really fast, the third is slow, and then its back to fast.

@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 22, 2014

Contributor

Just so we're on the same page, if you put the first external initialization inside the instantiate loop you get much better results,

            time("instantiate");
            var arr = [], l=100000;
            for (var i=0; i<l; i++) {
                var mtx = new ns.Matrix2D();

                if (i&1) { mtx.compositeOperation = "foo"; }
                if (i&2) { mtx.alpha = Math.random(); }
                if (i&4) { mtx.shadow = {}; }
                if (i&8) { mtx.visible = false; }

                arr.push(mtx);
            }
            endTime("instantiate", true);

so that seems to count as an extremely cheap first external assignment, and allows later assignments take the fast path.

I'm guessing this has something to do with the Inline Cache, but I can't currently say what, or how we could force it into the above state using only code inside the class.

However, it may be much more common in practice to configure the matrix as soon as it's been created.

Contributor

MannyC commented Oct 22, 2014

Just so we're on the same page, if you put the first external initialization inside the instantiate loop you get much better results,

            time("instantiate");
            var arr = [], l=100000;
            for (var i=0; i<l; i++) {
                var mtx = new ns.Matrix2D();

                if (i&1) { mtx.compositeOperation = "foo"; }
                if (i&2) { mtx.alpha = Math.random(); }
                if (i&4) { mtx.shadow = {}; }
                if (i&8) { mtx.visible = false; }

                arr.push(mtx);
            }
            endTime("instantiate", true);

so that seems to count as an extremely cheap first external assignment, and allows later assignments take the fast path.

I'm guessing this has something to do with the Inline Cache, but I can't currently say what, or how we could force it into the above state using only code inside the class.

However, it may be much more common in practice to configure the matrix as soon as it's been created.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 23, 2014

Member

Wow, you're not kidding. This just gets more bizarre and esoteric the further we go.
instantiate: 36ms props1: 11ms props2: 10ms calculate: 5ms total: 62ms

Basically the same test as you, except I am initing all the properties. I'm actually not sure why yours wouldn't be running into the megamorphic issues, since you're defining 16 different combinations of properties.

Member

gskinner commented Oct 23, 2014

Wow, you're not kidding. This just gets more bizarre and esoteric the further we go.
instantiate: 36ms props1: 11ms props2: 10ms calculate: 5ms total: 62ms

Basically the same test as you, except I am initing all the properties. I'm actually not sure why yours wouldn't be running into the megamorphic issues, since you're defining 16 different combinations of properties.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 23, 2014

Member

Ok. So the difference in performance between defining the properties in the initialize method vs the test loop is entirely due to the fact that we were assigning a float in the loop, but an integer in initialize. If you have initialize set alpha to 1.000001 instead, it performs exactly the same as the loop.
instantiate: 27ms props1: 7ms props2: 6ms calculate: 4ms total: 44ms

So with that mystery solved, it looks like we can make this (and likely other) classes faster by initializing instance values (per the OP). It raises a new question though, can we hint to the browser that these are float values, without requiring bizarre values? As expected, setting to 1.0 doesn't help. Setting it to a float, then immediate to an int works, but is still pretty hacky:
this.alpha = .1; this.alpha = 1;

I guess it's not the biggest issue, since it only affects the first assignment, but it would still be nice to address if possible.

To google!

Member

gskinner commented Oct 23, 2014

Ok. So the difference in performance between defining the properties in the initialize method vs the test loop is entirely due to the fact that we were assigning a float in the loop, but an integer in initialize. If you have initialize set alpha to 1.000001 instead, it performs exactly the same as the loop.
instantiate: 27ms props1: 7ms props2: 6ms calculate: 4ms total: 44ms

So with that mystery solved, it looks like we can make this (and likely other) classes faster by initializing instance values (per the OP). It raises a new question though, can we hint to the browser that these are float values, without requiring bizarre values? As expected, setting to 1.0 doesn't help. Setting it to a float, then immediate to an int works, but is still pretty hacky:
this.alpha = .1; this.alpha = 1;

I guess it's not the biggest issue, since it only affects the first assignment, but it would still be nice to address if possible.

To google!

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 23, 2014

Member

Interestingly, initializing the core matrix values (a,b,c,tx, etc) as floats has a pretty major impact on the props loops, even though the properties aren't even being accessed in those tests.
instantiate: 51ms props1: 27ms props2: 35ms calculate: 6ms total: 120ms

Member

gskinner commented Oct 23, 2014

Interestingly, initializing the core matrix values (a,b,c,tx, etc) as floats has a pretty major impact on the props loops, even though the properties aren't even being accessed in those tests.
instantiate: 51ms props1: 27ms props2: 35ms calculate: 6ms total: 120ms

@MannyC

This comment has been minimized.

Show comment
Hide comment
@MannyC

MannyC Oct 23, 2014

Contributor

Basically the same test as you, except I am initing all the properties. I'm actually not sure why yours wouldn't be running into the megamorphic issues, since you're defining 16 different combinations of properties.

I am/was setting them in the constructor first, then altering (some of) them in the init loop.

Good stuff on the float vs int front. Some quick googling hasn't yet revealed an easy way to force 1.0 to be represented as a float.

ES6 is coming with Number.EPSILON

The value of Number.EPSILON is the difference between 1 and the smallest value greater than 1 that is representable as a Number value, which is approximately 2.2204460492503130808472633361816 x 10‍−‍16.

So we could try 1 - Number.EPSILON or 1 + Number.EPSILON, being 0.9999999999999998 and 1.0000000000000002 respectively. We'd have to use the number as the property won't be supported in enough browsers. I'm not sure what issues this could throw up though. The numbers do have the distinction of being the closest thing to 1 without being 1, so they at least have logic to them.

Contributor

MannyC commented Oct 23, 2014

Basically the same test as you, except I am initing all the properties. I'm actually not sure why yours wouldn't be running into the megamorphic issues, since you're defining 16 different combinations of properties.

I am/was setting them in the constructor first, then altering (some of) them in the init loop.

Good stuff on the float vs int front. Some quick googling hasn't yet revealed an easy way to force 1.0 to be represented as a float.

ES6 is coming with Number.EPSILON

The value of Number.EPSILON is the difference between 1 and the smallest value greater than 1 that is representable as a Number value, which is approximately 2.2204460492503130808472633361816 x 10‍−‍16.

So we could try 1 - Number.EPSILON or 1 + Number.EPSILON, being 0.9999999999999998 and 1.0000000000000002 respectively. We'd have to use the number as the property won't be supported in enough browsers. I'm not sure what issues this could throw up though. The numbers do have the distinction of being the closest thing to 1 without being 1, so they at least have logic to them.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 23, 2014

Member

I think my next step is going to be creating a slightly more real-world test, like moving 50k DOs around a stage, and apply this change to Matrix2D and DisplayObject to see what kind of actual impact it has. I'll test both with and without hinting the float using the double assignment trick above.

Member

gskinner commented Oct 23, 2014

I think my next step is going to be creating a slightly more real-world test, like moving 50k DOs around a stage, and apply this change to Matrix2D and DisplayObject to see what kind of actual impact it has. I'll test both with and without hinting the float using the double assignment trick above.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 24, 2014

Member

Ok. Hacked together a REALLY rough test. In brief, it creates 200 Containers on stage, each with 200 Shapes pointing to a simple shared Graphic (2px red square). So, 40200 display objects total. They are assigned random x/y positions and a random set of properties (rotation, skewX, skewY, alpha).

Each frame, each object (both Containers and Shapes) has a set of props updated based on its index (so potentially different from the setup props). I measure the initial setup time (instantiation and setting the props). Each frame I measure the time it takes to update the props and run stage.update().

Here are the results for the first 5 frames with the current NEXT build:

setup 57.52ms

updateProps 18.47ms
render 378.79ms
updateProps 21.23ms
render 321.79ms
updateProps 8.44ms
render 342.44ms
updateProps 12.14ms
render 253.70ms
updateProps 8.19ms
render 238.57ms

And here are the results after adding instance based properties to DisplayObject and Matrix2D:

setup 127.47ms

updateProps 12.23ms
render 353.83ms
updateProps 9.01ms
render 219.18ms
updateProps 2.30ms
render 197.26ms
updateProps 4.15ms
render 260.55ms
updateProps 2.23ms
render 246.61ms

Seems to be about the trend we would expect. Higher initial setup cost, noticeably faster property updates (100-200%), and stabilizing on a slightly faster render/update pass (~15-20%). Most of the cost of an update is going to be the actual pixel fill, which will be unaffected by this.

I'm going to write a canvas stand-in based on my Context2DLog to eliminate the pixel fill costs and isolate the library.

Member

gskinner commented Oct 24, 2014

Ok. Hacked together a REALLY rough test. In brief, it creates 200 Containers on stage, each with 200 Shapes pointing to a simple shared Graphic (2px red square). So, 40200 display objects total. They are assigned random x/y positions and a random set of properties (rotation, skewX, skewY, alpha).

Each frame, each object (both Containers and Shapes) has a set of props updated based on its index (so potentially different from the setup props). I measure the initial setup time (instantiation and setting the props). Each frame I measure the time it takes to update the props and run stage.update().

Here are the results for the first 5 frames with the current NEXT build:

setup 57.52ms

updateProps 18.47ms
render 378.79ms
updateProps 21.23ms
render 321.79ms
updateProps 8.44ms
render 342.44ms
updateProps 12.14ms
render 253.70ms
updateProps 8.19ms
render 238.57ms

And here are the results after adding instance based properties to DisplayObject and Matrix2D:

setup 127.47ms

updateProps 12.23ms
render 353.83ms
updateProps 9.01ms
render 219.18ms
updateProps 2.30ms
render 197.26ms
updateProps 4.15ms
render 260.55ms
updateProps 2.23ms
render 246.61ms

Seems to be about the trend we would expect. Higher initial setup cost, noticeably faster property updates (100-200%), and stabilizing on a slightly faster render/update pass (~15-20%). Most of the cost of an update is going to be the actual pixel fill, which will be unaffected by this.

I'm going to write a canvas stand-in based on my Context2DLog to eliminate the pixel fill costs and isolate the library.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 24, 2014

Member

Tested with "FauxCanvas", which I think I will push to /extras/ - it's pretty handy, and results in much more consistent times. I'll avoid the wall of text this time - I'm seeing the following when using instance definitions:

setup: ~20-100% slower (highly variable)
updateProps: ~250% faster
render: ~150% faster

Looks like this is definitely worth pursuing. I've been considering revisiting our class model anyway, and this seems like a more concrete excuse than "because I don't love what we have".

Member

gskinner commented Oct 24, 2014

Tested with "FauxCanvas", which I think I will push to /extras/ - it's pretty handy, and results in much more consistent times. I'll avoid the wall of text this time - I'm seeing the following when using instance definitions:

setup: ~20-100% slower (highly variable)
updateProps: ~250% faster
render: ~150% faster

Looks like this is definitely worth pursuing. I've been considering revisiting our class model anyway, and this seems like a more concrete excuse than "because I don't love what we have".

@zardilior

This comment has been minimized.

Show comment
Hide comment
@zardilior

zardilior Oct 26, 2014

Cant you simply cast it a float? //i fuese there is a good reason for no but whatever

Cant you simply cast it a float? //i fuese there is a good reason for no but whatever

@gskinner gskinner removed the UTR label Oct 27, 2014

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Oct 27, 2014

Member

I've pushed a branch that implements this change in addition to a modified class model. In my testing I am seeing ~2-2.5x speed up of Stage.update() with a FauxCanvas (ie. no browser rendering costs.

https://github.com/CreateJS/EaselJS/tree/classRearchitecture

It's basically completely untested right now, and I'd appreciate any feedback or testing anyone can provide.

Member

gskinner commented Oct 27, 2014

I've pushed a branch that implements this change in addition to a modified class model. In my testing I am seeing ~2-2.5x speed up of Stage.update() with a FauxCanvas (ie. no browser rendering costs.

https://github.com/CreateJS/EaselJS/tree/classRearchitecture

It's basically completely untested right now, and I'd appreciate any feedback or testing anyone can provide.

@gskinner

This comment has been minimized.

Show comment
Hide comment
@gskinner

gskinner Nov 11, 2014

Member

Resolved in #509.

Member

gskinner commented Nov 11, 2014

Resolved in #509.

@gskinner gskinner closed this Nov 11, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment