|
6 | 6 | {
|
7 | 7 | "imports": {
|
8 | 8 | "lit-html": "https://esm.sh/[email protected]",
|
| 9 | + "react": "https://esm.sh/[email protected]", |
| 10 | + "react-dom/": "https://esm.sh/[email protected]/", |
9 | 11 | "uhtml": "https://esm.sh/[email protected]"
|
10 | 12 | }
|
11 | 13 | }
|
12 | 14 | </script>
|
13 | 15 | <link rel="stylesheet" href="./index.css">
|
14 | 16 | </head>
|
15 | 17 | <body>
|
16 |
| - <div> |
17 |
| - <div class="label">test fixture</div> |
18 |
| - <pre id="fixture" class="output"></pre> |
| 18 | + <div id="inject" class="test"> |
| 19 | + <div class="label">inject</div> |
| 20 | + <div class="output"></div> |
19 | 21 | </div>
|
20 |
| - <div> |
21 |
| - <div class="label">default</div> |
22 |
| - <pre id="default" class="output"></pre> |
| 22 | + <div id="initial" class="test"> |
| 23 | + <div class="label">initial</div> |
| 24 | + <div class="output"></div> |
23 | 25 | </div>
|
24 |
| - <div> |
25 |
| - <div class="label">lit html</div> |
26 |
| - <pre id="lit-html" class="output"></pre> |
| 26 | + <div id="update" class="test"> |
| 27 | + <div class="label">update</div> |
| 28 | + <div class="output"></div> |
27 | 29 | </div>
|
28 |
| - <div> |
29 |
| - <div class="label">µhtml</div> |
30 |
| - <pre id="uhtml" class="output"></pre> |
31 |
| - </div> |
32 |
| - <p> |
33 |
| - This tests the performance of <code>html</code> and <code>render</code>. |
34 |
| - By testing <em>only</em> these two functions, we isolate time spent by the |
35 |
| - templating engine from time spent by the element base class. |
36 |
| - </p> |
37 |
| - <p> |
38 |
| - The term “inject” refers to the process of taking an array |
39 |
| - of template strings, injecting special markup strings, instantiating a |
40 |
| - <code><template></code> element, mapping DOM elements based on the |
41 |
| - special markup previously injected, cloning that template element, and |
42 |
| - finally rendering it within a container element. Injection happens only |
43 |
| - <em>once per template function declaration</em>. This is the most |
44 |
| - time-consuming step of the process, but it also is only typically needed |
45 |
| - once per element base class definition. |
46 |
| - </p> |
47 |
| - <p> |
48 |
| - The term “initial” refers to the process of taking a |
49 |
| - template that’s <em>already</em> been injected and rendering it into |
50 |
| - a new container element. For example, if you render multiple elements in |
51 |
| - the page, the templating function is likely shared — this means that |
52 |
| - the engine can skip the <em>injection</em> phase altogether. This happens |
53 |
| - whenever a new element of the same type is created (i.e., the same element |
54 |
| - appearing in a list over-and-over again). |
55 |
| - </p> |
| 30 | + <p><b> |
| 31 | + For simplicity, these tests do not run in a cross-origin isolated |
| 32 | + environment. That means that “performance.now” timestamps will |
| 33 | + only be accurate to roughly “100 µs”. To combat this, |
| 34 | + tests are run in batches so that each time delta is large enough so that |
| 35 | + the cross-origin discrepancy would add at most ~2% of error. |
| 36 | + </b></p> |
| 37 | + <p><b> |
| 38 | + Also, consider how developer tools windows or multiple tabs may impact |
| 39 | + these tests — i.e., take all of this information with a major grain |
| 40 | + of salt. The goal here is just to show the <em>relative</em> performance |
| 41 | + of a handful of engines. |
| 42 | + </b></p> |
| 43 | + <p><b> |
| 44 | + Each asterisk represents a percentile of the underlying data. The median |
| 45 | + (p50) is highligted in the chart and printed next to the related |
| 46 | + engine’s name. The first and last few percentiles are omitted to |
| 47 | + reduce jumpiness in the charts from run-to-run. |
| 48 | + </b></p> |
56 | 49 | <p>
|
57 |
| - The term “update” refers to the process of changing the values |
58 |
| - which are interpolated into a given template. This is the most common |
59 |
| - thing the engine needs to do. |
| 50 | + The term “inject” test refers to the process of starting from |
| 51 | + some completely-zero state. I.e., new container DOM and a fresh template. |
| 52 | + The term “initial” test is nearly identical to |
| 53 | + “inject” in setup, but it’s possible that the package |
| 54 | + has cached some computations related to the input template strings (note |
| 55 | + that the container here is still created from scratch). The term |
| 56 | + “update” test is the most fine-grained test (given a |
| 57 | + pre-existing container that’s already been set up, how long does it |
| 58 | + take to simply <em>update</em> the managed DOM). |
60 | 59 | </p>
|
61 | 60 | <p>
|
62 |
| - Finally, a note on how the tests work — they are batched up and run within |
63 |
| - animation frames to guard against any interference that might occur when |
64 |
| - an animation frame is skipped due to the main thread being busy. This is |
65 |
| - why the tests all take the same amount of time to complete. |
| 61 | + Finally, a note on how the tests work — they are batched up and run |
| 62 | + within animation frames to guard against any interference that might occur |
| 63 | + when an animation frame is skipped due to the main thread being busy. This |
| 64 | + is why the tests all take the same amount of time to complete even though |
| 65 | + the actual tasks they measure can differ. |
66 | 66 | </p>
|
67 | 67 | <script type="module" src="./index.js"></script>
|
68 | 68 | </body>
|
|
0 commit comments