more documentation

This commit is contained in:
Matthew Griffith 2020-08-16 10:23:37 -04:00
parent 7cf49623c7
commit 88a5f8798d
2 changed files with 28 additions and 4 deletions

View File

@ -36,9 +36,9 @@ The only configurable option is what to name the generated js file.
```
elm-optimize Main.elm --output app.js
```
**Note** elm-optimize only generates a js file, it doesn't support generating HTML.
**Note** elm-optimize only generates a js file, it doesn't support generating HTML.
**Another Note** Before deploying your app, you should also minify it and gzip it. `elm-optimize` does not do that for you. [Check out this doc for a recommended setup.](minification.md)
**Another Note** Before deploying your app, you should also minify it and gzip it. `elm-optimize` does not do that for you. [Check out this doc for a recommended setup.](minification.md)
## Exploration
@ -58,11 +58,13 @@ In an effort to quantify these transformations, we've put together a number of b
Our goal is to have benchmarks that track performance on code where performance is meaningful.
[Here's the most recent, comprehensive run of the benchmarks.](results/current.md)
[Here's the most recent, comprehensive run of the benchmarks.](data/current.md)
Though here are a few highlights:
*Note* keep in mind that these numbers have *all the caveats* that benchmarks usually have.
**Note** — keep in mind that these numbers have *all the caveats* that benchmarks usually have. You may not see similar numbers depending on your machine, your browser, subtle differences in your code, etc.
**Another Note** — From what we've seen, given that you're [minifying and gzipping your JS](minification.md), these transformations should either have no effect on asset size, or may even make your app slightly smaller.
## Html

22
data/current.md Normal file
View File

@ -0,0 +1,22 @@
# Most Recent Results
*Note* keep in mind that these numbers have *all the caveats* that benchmarks usually have.
Namely that
1. There's a certain amount of noise in each of these runs. Numbers commonly vary as much as 5% between runs, and sometimes may will vary much more depending on what else is happening on the computer. We can likely be better in this regard, though the speedups we're looking for are usually fairly dramatic.
2. Different code will be affected differently. We tried to get a set of benchmarks that are directly relevant to people, but it's an ongoing endeavor.
We track both benchmark performance and minified+gzipped asset size.
[Here are the general results](data/results.current.md).
As well, we also did a more detailed run called a *knockout* run.
This is where we went through each transformation individually, turned it off, and ran the benchmark again.
This allows us to see how transformations work in the context of the other transformations that are operating.
[Here are the results of the knockout run.](data/results.knockout.md)