iamstef

In my experience, these add up real quick and are often indicators of a larger "instability" issue that remains well after the "deopt churn" appears to settle, but continues manifests in the form of some heavy GC.

Note: many internal structures related to the JIT (IC/hidden classes/code gen etc) can themselves cause sufficient GC pressure, as can the code you described as "de-opted permanently".

Interestingly it is also possible for the above mentioned GC pressure to itself cause some fun (even more GC pressure): https://bugs.chromium.org/p/v8/issues/detail?id=5456

This may not be the root of your issue, but I would be careful to rule it out entirely to quickly.

Anyways, best of luck!

Comment · 10 years ago

You may want to give the follow script a try:

* https://gist.github.com/krisselden/d3ce3cbb37cc6035b0927fdbf...

It flips some handy flags providing useful output, this output can quickly illuminate issues the regular tools do not (yet).

Running this on the example you linked to bellow, shows that a series of functions are deopting and optimizing repeatedly. most likely causing at-least some of the sawtooth pattern you see.

example output (likely related to the problem):

  ```
  removing optimized code for: r.getViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r.getViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r._computeViewMatrix]
  [removing optimized code for: r._isSynchronizedViewMatrix]
  [removing optimized code for: r._isSynchronized]
  [removing optimized code for: r.getViewMatrix]
  ```

---

note: Credit for this should go to @krisselden the author of the above gist not me.

Comment · 10 years ago

and its easily swappable: https://github.com/switchfly/ember-cli-mocha (and fully integrates with the existing test harness, regardless of the test framework you choose.)

Comment · 10 years ago

Abstractions aim to hide complexity until one requires them.

As a developer, one becomes productive when one realize when to put the blinders on, and when to take them off. As such I for one, love that I don't need knowledge of x86 assembler, chip design, or signal processing until the problem at hand actually requires them.

Ember-cli aspires to keep developers focused on features, not orthogonal tech. That is unless they need to peel back that layer of the onion, and dive in. Even then, the goal is for only a few community members to dive in, explore the problem space, and ultimately contribute the solution. Next release, all community members benefit, without also having to invest (until the point where they have a specific itch to scratch).

Abstractions hurt when they leak, as such we must aspire to provide the best abstractions we can (at each layer), and this is only possible in collaboration with an eager and enthusiastic community.

An symptom of a curated solution, is all aspects of the stack evolve to work together. Mitigate abstraction leaks at the various boundaries.

Comment · 10 years ago

As someone who is:

* OSS user (and signee of the Dear Github letter)

* paid user

* user of an enterprise installation of Github

I can honestly say the problems I see in OSS land, are the same shape as those in paid, and the enterprise installation. The difference is, due to the volume of usage the enterprise installation suffers from these same issues even more.

Now, we may not see +1 DOS often (on the enterprise side of this), largely because its seen as bad manners and/or the goals are already shared via some other disjoint medium. But this doesn't mean the issue isn't present.

Being able to enforce additional semantics (such as priority/interest, reviewers, blocked by etc.) would be a big win

Comment · 11 years ago

> Handlebars (Ember's templating engine)

Just a pedantic touchup, ember does not use Handlebars (it once, several years ago did) Now it uses something (Glimmer) which shares some syntactic similarities, but usage/implementation have diverged.

Comment · 11 years ago

First of all, let me share a wonderful (and performant) mobile app, written in ember. It uses ember-data to connect/normalize the iTunes api, and provide a slick fast mobile experience.

https://fnd.io/

Disclaimer, I work on & with Ember.js (and I didn't work on https://fnd.io)

I've worked on several mobile web apps using ember, and performance did require being careful, but often "being careful" was nicely aligned with the mobile UX people expect. Small screen, put less stuff on it. etc.

Often times, we do see issues with ember on mobile, typically this is due to deeply nested loops of UI components being rendered. And most often, performance on mobile was an after-thought.

PSA: Regardless which framework (or no framework) you use, if you are shipping to mobile. Test/develop on your target mobile devices from day 1, you will not have any surprises, and you can catch performance related issues before they fester.

As for the discourse post, there are some issues ember is working to improve. If one reads further, it outlines the largest concern being the growing gap between JSC (Safari, which offers near desktop performance for discourse on mobile) and V8 (which doesn't do so well on mobile for discourse) performance. Year over year, the iOS experience is improving, but the android/v8 experience does not appear to.

The TL;DR of the issue (as is currently understood), is JSC handles dynamic code better, whereas v8 does not (yet) and Ember should both reduce the dynamism and continue to do less work. Which will continue to improve the experience for all consumers.

This is actually quite an interesting issue with lots of details, I could go on, but this is likely not best place for anything in depth.

The important part being, all parties involved are working towards (and together) on a better faster more wonderful future.

Ember with another (faster) iteration if its rendering engine: https://github.com/tildeio/glimmer (written in TypeScript), V8 with turbofan and the team, working together to improve JavaScript in the browser for everyone.