[WIP] Support router serialization.

[nathanhammond]

Currently works for all scenarios excepting late-additions via delegate. This may support those and I may just have broken tests, but I'm unsure.

Current status:

• Make it work.
• Make it right.
• Make it fast.

[chadhietala]

This probably the parse error.

[nathanhammond]

Uh-oh, benchmarks aren't good:

testing
- End-to-end (runs the mapping and generates the router)
- Serialized (loads from JSON)
running first test, please wait...
  End-to-end ............ 178.20 op/s
  Serialized .............. 0.69 op/s

I'm not sure why it's slow yet.

[chadhietala]

This is looking at the wrong RR instance.

[nathanhammond]

Good catch, rerunning benchmark now.

[nathanhammond]

No faster: it wouldn't be, thinking about it. That new RouteRecognizer(serialized); is stupidly expensive for some reason.

[nathanhammond]

@krisselden Can I steal some of your time to learn what I'm doing wrong on the performance side here? I'm going to delay aiming for 100% compatibility until I know it makes sense to do so.

Edit: see below, "simple" problem. No need to involve you yet. 😛

[nathanhammond]

Found the problem:

$ ls -la out.json 
-rw-r--r--  1 user  group  63414305 May  3 18:44 out.json

JSON.parse simply can't handle a 60mb JSON object. Also, can you say memory pressure? This needs to be optimized (and I think it can be, pretty dramatically).

[nathanhammond]

Can we start having the conversation about whether/how to land the dramatic refactoring currently living in trie.js once I finish making it 100% API compatible?

[nathanhammond]

166 assertions of 178 passed, 12 failed.

Closing in on correct, taking a look at early benchmarks. Add and End-to-end seem to be doing something terribly wrong; I suspect that the compact method needs some work. The recognize benchmark is effectively a worst-case-scenario as the generated flat list doesn't lend itself to prefix trie optimizations.

We're likely going to trade runtime performance for serialized performance here (in add), but I want to keep runtime within striking distance of serialized. This means that Add and End-to-end need to reach hundreds of op/s.

I need to rebuild serialization for the trie method to see what we're looking at for rehydration speed as well as JSON file size.

---

Benchmark	Original	Trie
Add	489.09 op/s	Crash
End-to-end	229.27 op/s	0.54 op/s
Generate	4,032,441.12 op/s	1,467,045.61 op/s
Handlers For	29,003,809.27 op/s	18,566,106.55 op/s
Recognize	352,315.79 op/s	25,253.27 op/s
Serialize	0.69 op/s

[nathanhammond]

New benchmarks with JIT compacting. JIT compacting spreads out the cost in recognize and generate making the first call to each super-slow. I'm guessing, based upon the non-existent benchmark change, that it's throwing out that run as an outlier. 😜 (Assuming that most differences here are just noise.)

Benchmark	Original	Trie	JIT Trie
Add	489.09 op/s	Crash	442.14 op/s
End-to-end	229.27 op/s	0.54 op/s	0.59 op/s
Generate	4,032,441.12 op/s	1,467,045.61 op/s	2,790,745.38 op/s
Handlers For	29,003,809.27 op/s	18,566,106.55 op/s	17,657,366.47 op/s
Recognize	352,315.79 op/s	25,253.27 op/s	25,979.61 op/s
Serialize	0.69 op/s

Updates:

• Improved generate by using push instead of unshift.
• Improved add by using pure loops.

[nathanhammond]

Current status:

• Rebased on top of @bantic's work. 339 out of 355 tests passing. I know of additional correctness issues that I need to revisit with regards to specificity that we don't have tests for.
• Many tests now run after a serialization/deserialization pass to check for idempotence of that operation.
• I've not re-reviewed performance recently.
• I need to clean up some of the mess I've made in integrating @bantic's work.

[nathanhammond]

Superseded by ember-route-recognizer.