You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As we move to different ways of building the Studio, it's important to test all functionality across existing and new build configuration. This PR adds a matrix option for auto-updating studios (with the potential of adding more). It also adds some conditional scripting logic to ensure that studios build and run according to the matrix configuration parameter.
In addition, it adds and updates tests that depend on a studio built with the auto-updates parameter.
What to review
The changed Github workflow. I have a few specific questions:
Are we okay with config: [auto-updating, default]? Are there better names for what we want to express?
Should we also add logic for additional datasets depending on whether or not the studio is auto-updating?
Testing
The specific tests added in this PR should pass under both conditions. All other tests should pass under both conditions.
efps — editor "frames per second". The number of updates assumed to be possible within a second.
Derived from input latency. efps = 1000 / input_latency
Detailed information
🏠 Reference result
The performance result of sanity@latest
Benchmark
latency
p75
p90
p99
blocking time
test duration
article (title)
46ms
51ms
64ms
206ms
219ms
12.0s
article (body)
18ms
21ms
26ms
68ms
94ms
5.7s
article (string inside object)
40ms
44ms
50ms
81ms
162ms
7.3s
article (string inside array)
44ms
47ms
65ms
84ms
276ms
7.6s
recipe (name)
21ms
23ms
27ms
41ms
0ms
8.2s
recipe (description)
19ms
20ms
23ms
33ms
0ms
4.7s
recipe (instructions)
6ms
8ms
10ms
11ms
0ms
3.2s
synthetic (title)
56ms
60ms
78ms
396ms
878ms
13.8s
synthetic (string inside object)
52ms
55ms
62ms
490ms
1003ms
8.5s
🧪 Experiment result
The performance result of this branch
Benchmark
latency
p75
p90
p99
blocking time
test duration
article (title)
48ms
51ms
54ms
94ms
65ms
11.3s
article (body)
19ms
21ms
30ms
85ms
102ms
5.5s
article (string inside object)
43ms
46ms
64ms
77ms
206ms
7.6s
article (string inside array)
48ms
52ms
57ms
187ms
141ms
7.7s
recipe (name)
21ms
22ms
26ms
62ms
0ms
7.7s
recipe (description)
18ms
19ms
21ms
31ms
0ms
4.6s
recipe (instructions)
6ms
8ms
9ms
10ms
0ms
3.2s
synthetic (title)
54ms
56ms
63ms
395ms
728ms
13.4s
synthetic (string inside object)
54ms
57ms
87ms
511ms
1189ms
8.7s
📚 Glossary
column definitions
benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
test duration — how long the test run took to complete.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RESOLVES SDX-1412
Description
As we move to different ways of building the Studio, it's important to test all functionality across existing and new build configuration. This PR adds a matrix option for auto-updating studios (with the potential of adding more). It also adds some conditional scripting logic to ensure that studios build and run according to the matrix configuration parameter.
In addition, it adds and updates tests that depend on a studio built with the auto-updates parameter.
What to review
The changed Github workflow. I have a few specific questions:
config: [auto-updating, default]
? Are there better names for what we want to express?Testing
The specific tests added in this PR should pass under both conditions. All other tests should pass under both conditions.