Ember RC6 and phonegap slow


#1

Hello I’m new to ember, and phonegap. But when i wrap the tom dale’s https://github.com/tildeio/bloggr-client ember guide changed the
adapter: DS.RESTAdapter.extend({ url: 'http://localhost:3000’ to point out to my server.

On desktop everything fine, upgraded to ember RC5 and fine on desktop AND phonegap on my galaxy tab2 but when i upgrade to RC6 it becomes really slow on the phonegap app, desktop stay fast.

anyone experiencing the same?


How do we beat AngularJS in the developers mindset?
#2

Really? nobody using phonegap?


Is it possible to create performant mobile Apps for Native Deployment based on EmberJS? Where are the limits?
#3

I’m hearing this more and more; can you confirm that it is the transitions that are slow? And not just user interactions in general?


#4

thanks for reply-ing

in tom dales example

it takes up to 1 minute in rc6 before it shows the list of posts (i have like 20 posts to list) in rc5 it takes 1-2 seconds.

no click made yet, just the first page that shows the posts list.

this difference is only when wrapped with phonegap, on desktop there is no difference, rc5 and rc6 are really fast


#5

I’m seeing a really slow rendering with RC6. The browser will just stay blank until all of the GET requests have come back and then it will render the page. I did not experience this in RC5 or before.


#6

Seems that when nobody can answer this within a week, noone working on ember really cares about the use of ember in mobile apps, which leaves me to think that future ember will not bother to be compatible with mobile apps either. Lost of tme learning ember

Really a pitty cause it was my favourite

Just my 2 cents but future might be more and more apps instead of desktop like browsing the www


#7

I noticed a slowdown in my App on mobile, just browser right now, but possible I will use PhoneGap to wrap it in the future.

Have you tried using the minified RC6? I’ve only tried with development but what I can say is that something changed from RC5->RC6 that is causing my app to run slower and causing performance issues with other javascript libraries in my app.

David, if you learned your time wasn’t lost. Also I think I and others intend to use Ember in mobile apps, so lets figure out why RC6 has mobile performance issues, and fix them.


#8

@David_Mulder these issues will absolutely be addressed. Mobile performance is hugely important to the core team, but fixing the router was the highest priority for RC6. In the meantime, perhaps it’s best that you keep your app on RC5 until these perf issues are addressed, which should be shortly.


#9

@David_Mulder @SirZach so this might actually just be due to the change in the way RC6 router will pause a transition if the context you pass to it from a transitionTo or a linkTo, or whatever you return from the model hook, is a promise (which Ember Data model objects presently are, even though that is likely to change very shortly since everyone agrees model objects should not themselves be promises).

I would expect that the way to confirm whether my theory is correct is to try and refresh your page right on that route, rather than transition into it via a linkTo, though obviously this doesn’t make sense if you’re using PhoneGap. Another thing you could try is to remove the .then property from these objects. Perhaps the best place to do that would be in the model hook; before returning the record, set .then = null and then return the record. This will bring back the old behavior of not pausing for a promise, and I bet this will fix your problem. If it doesn’t, then it may actually just be a perf issue, but this seems like the more likely culprit.


#10

@David_Mulder @SirZach I think I can confirm this suspicion. I was playing around with the promises embedded in ember-data models and record arrays a couple days ago and noticed that if I broke the promise such that it never resolved, the app would fail to load when refreshing on that route. Meaning: blank page, no debug transition logs.


#11

Yeah, the unresolving but un-erroring promises are a tricky one to debug. Not sure if some timeout would be helpful to have, perhaps at least on a dev build.


#12

Oh, that’s good to hear about the models presenting themselves as promises, that’s so annoying.


#13

Seems like the issue has already been identified but I figured that I would pipe in and say that I have been experience issues on mobile as well and that it only seems to happen on transitions. Everything else seems to be quite responsive and nice so I would assume that you are on the right track with the issue lying in the changes to the router. Keep up the great work I have been enjoying getting to know Ember and hope that some day I can be smart enough to help out on issues like this.


#14

@tmartineau can you comment on whether the problem has to do with the models you pass to the transitions or return from model have .then properties that are pausing the transition?


#15

Basically, I’d love to solve any perf issues that come up but I really need to have a confirmation (ideally a succinct jsbin/benchmark) that highlights these issues without it boiling down to the very much intended pausing behavior featured on the router now. @tmartineau do you think you could put together something quick that illustrates this issue?

Also, related: Splitting of Promises from DS.Model (or Ember.Model)


#16

Sorry for the late reply. I will see what I can do about throwing together an example. I wonder if it has something to do with the fact that I am using ember-model instead of Ember Data because of the odd situation I am in without control of the backend (and the fact that it will not be done properly). It could be something I am doing since I am new to the framework but rolling back to RC5 has helped to speed up the transitions. It is not an issue on more powerful devices… even on the iPad it is fine.


#17

Any updates on this? I couldn’t fine any issue up for this but i don’t want to make one and just refer to this discussion. I’m having the same problems with android and trigger.io.


#18

@eviltrout experienced similar issues which, according to him, all went away when he switched to a production build of Ember, which gets rid of the many Ember.asserts that were apparently slowing it down? So, make sure to try that before anything else.

In summary, there are three possibilities here about the reported slowness:

  1. People are confusing actual slower performance with the new pause-on-promise behavior of the RC6+ router.
  2. People are using development builds of Ember, which leave in all of the Ember.asserts which can slow things down in hot code paths (I believe @eviltrout reported 30% slowdown)
  3. There actually is a performance regression that unfortunately no one has been able to come up with a reproducible benchmark for (I’m not saying it’s not there, just that it’s often been 1 or 2 and no one’s sat down to make a benchmark that demonstrated that this is what’s actually happened)

#19

So i tried switching to a production build of Ember and indeed the performance hit no longer is there. But I’d say I didn’t have a 30% slowdown, more like 300%. I wonder what assert(s) made it that slow.

In any case; thanks for the quick reply!


#20

You guys might want to test if it’s this commit specifically that makes things slow: https://github.com/emberjs/ember.js/commit/f872a78760d5111b0e468a06389d549cb8832ab2

I had a similar issue on non-mobile and it turned out to be the horrible performance of the native assert: http://jsperf.com/chrome-assert-vs-ember-polyfill

I think, in my case the problem was noticeable because perhaps ember-tables has lots of asserts? I was also seeing very serious slow down on the magnitude of 100 or 1000% when using the developer version.