Screenshotter --fast argument speeds it up 6x.#752
Conversation
The slowest part of screenshotter tests is the page load, probably because so many assets must be loaded over the slow docker connection. On my laptop this takes ~4s per test. The `--fast` argument avoids this cost by rendering new TeX on the existing page. For second and subsequent tests, use `executeAsyncScript` to call KaTeX, rather than performing a full page + asset load. (If too many errors happen in `--verify` mode, we fall back to full loads.) On my laptop, a full verify (chrome + FF) used to take 12m20s+. With `--fast` it takes 2m23s.
|
This does not yet update travis to supply |
|
Works on Travis too so I made |
|
Tested locally and looks good to me! (3m8s) I tried tweaking @gagern, do you want to take a look at this to confirm? |
|
@kohler I'm super excited about this change. A lot of time and effort has gone into our current solution so I'm glad that you were able to iterate on it to speed it up in a reliable way. |
|
Had a look at the code, didn't run it. Approach looks sane enough, particularly with the fallback in place. Name of the option could be more descriptive. Perhaps |
|
Sure, good choice—renamed. |
| document.getElementById("post").innerHTML = query["post"] || ""; | ||
|
|
||
| if (callback && document.fonts && document.fonts.ready) { | ||
| document.fonts.ready.then(callback); |
There was a problem hiding this comment.
I didn't realize there was a document.fonts.ready was a thing. I've used webfontloader in the past, but this is better for this use.
| function loadMath() { | ||
| if (!opts.reload && driverReady) { | ||
| driver.executeAsyncScript( | ||
| "var callback = arguments[arguments.length - 1]; " + |
There was a problem hiding this comment.
I had to look this up in the selenium docs. It seems like such an awkward API for interacting with the browser. Thanks for figuring out all of this stuff.
The slowest part of screenshotter tests is the page load, probably
because so many assets must be loaded over the slow docker
connection. On my laptop this takes ~4s per test. The
--fastargument avoids this cost by rendering new TeX on the existing
page. For second and subsequent tests, use
executeAsyncScriptto call KaTeX, rather than performing a full page + asset load.
(If too many errors happen in
--verifymode, we fall back tofull loads.)
On my laptop, a full verify (chrome + FF) used to take 12m20s+.
With
--fastit takes 2m23s.