1.5.0 Performance Decrease

#1

I was curious if anybody has noticed a significant performance decrease going from 1.4.0 to 1.5.0. My app has gone from loading the home page in about 5 seconds to taking about 30 seconds. I don’t know what the exact cause is yet, but I know that it happens when I move from 1.4.0 to 1.5.0. Unfortunately, I don’t have more information right now. The code is all proprietary, so I’d have to do some significant work to get a JSBin set up showing the issue.

If anybody has experienced anything similar, I’d like to hear about it and possibly pinpoint my issue.

1.4.0 Profile

a52558498bd5789f.png694×468

1.5.0 Profile

2495ecd818f361f5.png700×227

#2

I’ve updated my post with screenshots of the profiles for each version. The only thing that changed between each was the version of Ember.js. And for 1.5.0, it seems to be spending a huge amount of time dealing with getters, dependencies and observers. What changed in Ember.1.50 that could have prompted this slowdown?

#3

Curious what happened as well~

#4

hopefully not, but this could be related to my performance tuning. We did thoroughly test across several big apps, with only positive throughput improvements.

Unfortunately I am likely unable (do to some personal stuff) take a closer look until sunday (maybe monday). If it is possible to provide me with access to the app (maybe via screen sharing session). I would love to dig in and see what is going on.

Please feel free to reach out to me via gtalk/email: stefan.penner@gmail.com or skype: stefanpenner

#5

What are the tuning you did?

#6

context for some of the tuning work:

#7

@gordon_kristan, You can quickly grab builds by their hash and drop them in to your app to try and bisect where the issue starts. For example:

http://builds.emberjs.com/canary/shas/00ea851652d8234d46e9482c655c9eb145936c93/ember.prod.js

#8

I hadn’t thought of using Git bisect. I’ll try that out on Monday to try to narrow things down a bit.

@stefan I can probably share the code with you and maybe setup a Heroku demo server or something. I’m out of town this weekend, so don’t worry about not getting to it immediately. I’ll see what other information I can dig up and I’ll contact you early next week.

#9

Hey @gordon_kristan, I would love to investigate your performance regression.

Have you had a chance let me know, I am eager to see your issues first hand.

#10

Here at Netflix, we’re seeing better performance with 1.5. Our friends at Discourse are seeing the same.

I hope @gordon_kristan can help us get to the bottom of his issue, but it appears to be an isolated incident at this time.

#11

Sorry guys, it’s been a busy week here and I nearly forgot about this since I temporarily switched back to 1.4.0. I don’t have much time here at work today, but I will have time later tonight. When I get home, I’ll gather the information I can then we’ll work through this. I have some suspicions of what might be causing it, but I want to double-check first.

#12

So I ran a really quick test just to see if I was crazy, and it turns out I’m not, I’m just really bad at using Ember observers. :stuck_out_tongue: In some of our proprietary persistence code, I was performing a large chunk of property updates, but I wasn’t wrapping them in beingPropertyChanges and endPropertyChanges. As soon as I did that, my times fell back to 1.4.0 times.

Here’s some pseudocode of the most troublesome method:

extractJsonPayload(json):
    for type in json:
        for id in json[type]:
            injectRecordIntoStore(json[type][id])
            // fires observers

As soon as I wrapped that method with beingPropertyChanges and endPropertyChanges, the speed was fine.

So I guess the real issue is that I was writing extremely inefficient code (no fault of Ember’s). However, it does raise the question: what exactly changed between 1.4.0 and 1.5.0 that caused that code to suddenly become too inefficient?

#13

@gordon_kristan I have some ideas, but I would love to get hands-on with your app and isolate the concrete problem.

I may also be able to help you come up with a more efficient way of handling these inefficient code-paths.

#14

@gordan_kristan, thanks for giving me access to your app!

With it, I was quickly able to track down and isolate the performance regression.

First of all, my initial assumption was wrong. The regression had nothing to do with my performance tuning, which I forgot hadn’t landed in 1.5. :wink:

The actual regression was a bug fix to ArrayComputed: https://github.com/emberjs/ember.js/commit/7af8beb0bb9e484ab7427b447f6b6dbb76b4aad8. That fix traded performance for correctness. After some thought, I believe we have a plan to restore performance, while still maintaining correctness. I have already spoken with @mmun and @hjdivad, and we plan to investigate it thoroughly this weekend.

I have also opened a corresponding GH issue. Let’s track ideas and solutions there. https://github.com/emberjs/ember.js/issues/4740

#15

updated: We have reverted the regression https://github.com/emberjs/ember.js/pull/4753 noted the original caveats, and are beginning steps to prepare a better solution.

Thanks again for the regression report, we hope to have a 1.5.1 release shortly.