Repository navigation
docs(perf): account for every merge up to develop d16ca71e0 in the 0.12.0 record - #1804
Merged
Merged
Conversation
….0 record Name develop df2bc17 as the candidate of the 0.12.0 performance record and account for each merge after e022cbc: #1793, #1794, #1787, #1788, #1752 and #1775 Go-neutral by diff; #1792 re-probed on the export rows at 86fa09e (neutral); #1795 and #1791 measured at a37809a on every row set (load and runtime rows unchanged, BatchSatisfy one allocation per assertion, export rows +0.1 %); Co-Authored-By: jason.han <hanhuijun@gmail.com> #1778 measured at df2bc17 on the runtime and gRPC rows (unchanged).
Contributor
Author
|
I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".
|
…te develop d16ca71 Co-Authored-By: jason.han <hanhuijun@gmail.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What and why
docs/project/performance-release-0.12.0-vs-0.11.0.mdnameddevelope022cbca0as the 0.12.0 candidate (#1788). Since thendeveloptook #1793, #1794, #1792, #1788, #1795, #1791, #1787, #1775, #1752, #1778, #1797 and #1785, six of them Go on measured paths. This amends the record's "After the measured heads" section to namedevelopd16ca71e0as the candidate and account for each of those merges, with the SHA each row set was measured at:git diff --stat … -- '*.go' go.mod go.sumquoted).86fa09ec9: neutral;WriteAPIJSONoutput byte-identical,ConvertAPIJSON/32and/128bytes and allocations unchanged.a37809a6cagainst86fa09ec9: load, REPL, derived and runtime rows unchanged in bytes and allocations (LoadModel/1000563.8 k allocations on both, so fix(semantics): Usage::mayTimeVary derives over the effective isComposite — a performed action or exhibited state varies in time #1784's finding stands as reported);BatchSatisfygains one allocation per assertion (+0.03 %, fix(runtime): a false assumption makes a requirement hold (assumptions imply constraints) #1791's verdict); the export rows grow +0.06–0.15 % (WriteAPIJSON) and +0.11–0.12 % (ConvertAPIJSON), the cost of fix(export): the usages a declaration implies state isVariable/mayTimeVary from their owning type; a requirement's subject derives Usage::mayTimeVary #1795'smayTimeVaryderivation per implied usage.tests/perfgRPC rows atdf2bc173cagainsta37809a6c: bytes and allocations equal or~on every row; binary +32 KiB.IsVariantguard inUsageMayTimeVary*) and refactor(export): split writtenRelationships into per-source helpers #1785 (export, theelement_ids.gosplit) — the load/derived rows and the export rows re-run atd16ca71e0againstdf2bc173c: bytes and allocations equal or~on every load, derived, runtime and gRPC row (LoadModel/1000563.8 k on both);WriteAPIJSONoutput byte-identical on four fixtures and 8 bytes larger onSimpleVehicleModel, which the diff of the two outputs attributes to fix(semantics): a variant usage has no owning type, so Usage::mayTimeVary derives false #1797 (its four variant usages'isVariable/mayTimeVarynowfalse), with 40–50 fewer allocations per op on those two rows;ConvertAPIJSON/32and/128unchanged; refactor(export): split writtenRelationships into per-source helpers #1785 leaves no trace in any row.Whole-binary floor, generated-model and Apollo 11 loads, the element-ID query and
-convert ttlwere re-run at each head (three runs after a warm-up) and stay inside their earlier spreads; sec/op rows that cross p < 0.05 do so on one column's spread and are not read, as the record's method says.How it was verified
Docs only.
python3 scripts/check-doc-links.pyreports only the pre-existingthird-party-notices.mdnotice link; no changelog fragment (docs/projectrecord, per the previous two record PRs). Benchmarks:benchstatover six interleaved rounds per comparison with hypervisor steal logged per round (0–3.7 %), the stressConvertAPIJSON/satellites=512skipped as in the earlier probes.Checklist
make testandmake lintpass locally (docs only; link check run)docs/projectrecord