[Loader] : calculate optimization.

[ezequiel]

This is a first attempt at optimizing Y.Loader, since it actually bubbled up as a bottleneck in a certain application. I simply rewrote _sort, which now utilizes a topological sort (a variation of a depth first search) to generate a valid dependency order.

Before

The following is a profile of Y.Loader's resolve method. _sort bubbled up as one of the slowest methods calculate calls (which, in turn, resolve calls), so I decided to start there.

Note: Inclusive time is the time spent in the function, and its children. Exclusive time is the time spent in just the function, excluding its children.

Operations/second of calculate:

┌──────────────────────────────────────────┐
│  Internet Explorer (11.0) / Windows 8.1  │
├──────────────────────────────────────────┤
│  94.766  ±3.3%                           │
└──────────────────────────────────────────┘

After

Operations/second of calculate:

┌──────────────────────────────────────────┐
│  Internet Explorer (11.0) / Windows 8.1  │
├──────────────────────────────────────────┤
│  263.343  ±3.2%                          │
└──────────────────────────────────────────┘

---

Notes:

• After the rewrite, the op/s rose from 94.766 to 263.343. That's a 177.9% difference!
• Five unit tests were tweaked because they relied on resolve(..).js or resolve(..).css returning a certain order. There are times in which the order does not matter. For example, order does not matter if both modules do not depend on one another. I've made comments on each of these tests.
• I'm still nervous as to whether there are any edge cases I haven't caught. All 11000+ unit tests are successful, and amongst them are ones with pretty good coverage (app).

@ekashida @caridy @apm

[clarle]

This is super cool! Did the iterative version of the toposort algorithm not work out though?

[juandopazo]

🤘

[ezequiel]

@clarle,

I was able to get the iterative version to work, but surprisingly it provided no speed increases (in IE 11, that is). The code was a lot hairier, too.

[apm]

Nice, looks promising.

[triptych]

looks like a win of the week to me :)

[clarle]

Sort required before running topological sort, or you'll end up getting various correct orderings for things that should be equivalent like:

autocomplete, widget, event-custom, node

And:

node, event-custom, widget, autocomplete

We want to have one ordering regardless of the order of the modules so the URLs can be more easily cached.

[caridy]

yeah, I was talking to @ezequiel about this, and whether or not the modules should be inserted in the internal registry already ordered (potentially from our build process), which means that a Y.use() will not have to trigger a calculation unless a custom module, or a overruled module is introduced thru ApplyConfig(), it sounds ideal, but we will have to validate this hypothesis.

[ericf]

Having reproducible URLs does sound ideal. Do we have that behavior today? If not, then I say we merge this as-is, then add that as another improvement.

[ezequiel]

@ekashida sorts the modules in his new combo handler encoder (https://github.com/ekashida/gallery/blob/master/src/gallery-pathogen-encoder/js/pathogen-encoder.js#L459). I suppose I can sort the modules before the URLs are made as an additional improvement to resolve in another pull request, as @ericf's stated.

[clarle]

@ezequiel This is still my favorite pull request of all time.