How to ensure that my pull request will not break performance? #64

Activity

1. dadhi commented on Mar 10, 2018

   

   dadhi

   on Mar 10, 2018

   Owner

   More actions

   Good question.

   • For now you can write the benchmark with BenchmarkDotNet in ..Benchmarks project.
   • Ensure the benchmarked case covers affected code path.
   • Create benchmark against normal Expression.Compile, and compare both compilation and delegate invocation. Save bm results.
   • Change code and repeat bm, compare new and old results.
2. dadhi

   added

   help wanted

   question

   on Jun 15, 2018
3. dadhi commented on Aug 31, 2018

   

   dadhi

   on Aug 31, 2018

   Last edited by dadhi

   Owner

   More actions

   Another idea from #115 discussion.

   • We may CompileFast the test delegate,
   • then decompile it to IL code
   • then use this IL to emit and CreateDelegate to get a minimal possible time (assuming singe threaded liniar compilation)
   • Compare the original and minimal compilation time so that the delta fits, e.g. 10%

   👍React with 👍1Reacted by dzmitry-lahoda
4. dadhi commented on Mar 3, 2025

   

   dadhi

   on Mar 3, 2025

   Owner

   More actions

   Maybe via https://github.com/AnthonyLloyd/CsCheck
5. jogibear9988 commented on Oct 24, 2026

   

   jogibear9988

   on Oct 24, 2026

   Contributor

   More actions

   Opened draft PR #564: #564

   It automates the before/after comparison requested here: exact PR base versus head, the same frozen BenchmarkDotNet workloads for both, Standard and LightExpression, compilation and warmed execution, tree construction, compilation plus first invocation (to account for deferred JIT), and managed allocations. It runs both revision orders on one runner and uploads the complete measurement artifacts.

   A separate trusted publisher posts the report on each PR. Reports for older head commits are marked Outdated and collapsed; reruns of the same head update its report. Fork benchmark jobs remain read-only, while the publisher validates data without executing PR code or artifact scripts.

   The initial phase is reporting only so we can observe hosted-runner variation before making regressions required checks. Local opt-in blocking policy and tests are included. The minimal-IL theoretical comparison discussed above is a separate experiment and is not implemented here. Automatic publishing starts once the publisher workflow is merged into master.
6. dadhi

   added a commit that references this issue on Oct 25, 2026

   ci: compare PR performance and publish head-specific reports safely

   ...

   9c1213b
7. dadhi commented on Oct 25, 2026

   

   dadhi

   on Oct 25, 2026

   Owner

   More actions

   closed by #564
8. dadhi

   closed this as completedon Oct 25, 2026