> Starting fresh somewhere else with no reputation, no karma, and the potential for being the small fish again will pay dividends.
This assumes new place will recognize the attributes that you bring, no?
This reminds me somewhat of the allure of rags-to-riches stories. Of a world (or a company, at least) where talent is consistently recognized and fairly rewarded.
One can hope that such places exist, to varying degrees, but it seems unwise to assume your next job is one of them, unless you have some solid evidence.
Nice, this was super timely as I was literally building the same thing. And I had just reached the part where I was annoyed that all the submitted videos had different shapes and sizes which as you know would be tedious to correct manually.
I know atleast one of these companies (I can't speak for the rest) had a pre-existing bi-lateral patent agreement with Facebook which rendered the react patent clause irrelevant, allowing them to use react without concern. Without that existing agreement this would not have been the case.
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.
Hrm. I've looked at deopts before, and I may be wrong but I think they aren't the issue. As I understand v8, it's normal at startup for hot functions to go through the opt/deopt cycle several times as the engine learns about them - and once a function does it too many times, it gets deopted permanently.
For this reason I always let the game run for 10-15 seconds before I profile, figuring that by that time most of the opt/deopt churn will be finished. And this (very useful) script seems to back this up - I get output like yours at startup, but if I wait a while and then rm the output files, further output is relatively minimal.
So I'm inclined to think that opt/deopt stuff isn't the issue, and there really are lots of JS heap objects getting allocated somewhere. At the same time though, when I used Chrome's built-in memory profiling I see a bunch of deopt-related strings, so maybe I'm way off base. If anyone sees what I'm missing please do clue me in.
> At the same time though, when I used Chrome's built-in memory profiling I see a bunch of deopt-related strings, so maybe I'm way off base
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".
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.
