Live-reloading performance regressions

[andymatuschak]

It appears that Babel-processing our prototypes has caused a significant performance regression—live-reloading now takes about 1.5s; it used to take a couple hundred ms.

If it's loading up Babel + source-map that's slow (as opposed to the actual transpiration), maybe we can improve this by keeping around a JS context with Babel + source-map, and we can reuse that context to transpile the transmitted JS, which we then evaluate in a new VM.

(cc @spicyj)

[jbrennan]

I wonder if we can take a page out of the live-editor codebase and do smarter reloads. They don’t reload the whole thing, they essentially eval + diff and only update what’s changed. It might be overkill, and it might not be a perf gain, but it could be a lot nicer than always resetting.

[andymatuschak]

Yep.

I think we should do both! What you mention sounds a lot harder. :)

On May 15, 2015, at 6:16 AM, Jason Brennan [email protected] wrote:

I wonder if we can take a page out of the live-editor codebase and do smarter reloads. They don’t reload the whole thing, they essentially eval + diff and only update what’s changed. It might be overkill, and it might not be a perf gain, but it could be a lot nicer than always resetting.

—
Reply to this email directly or view it on GitHub #84 (comment).

[jbrennan]

Harder, but already done by our fabulous CS team 💃

[sophiebits]

Probably won't have time to work on this soon, sorry.

(In my experience the live-editor patching was always a little finicky and I'd always have to do a full-reload a few times per session which was annoying enough for me that I would've personally rather it not try to preserve the state.)

[andymatuschak]

No worries, @spicyj, wasn’t expecting you to. :)

On May 19, 2015, at 9:23 PM, Ben Alpert [email protected] wrote:

Probably won't have time to work on this soon, sorry.

(In my experience the live-editor patching was always a little finicky and I'd always have to do a full-reload a few times per session which was annoying enough for me that I would've personally rather it not try to preserve the state.)

—
Reply to this email directly or view it on GitHub #84 (comment).