Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Configuration of IJsonAssertionOptions slows down comparison a log

未關閉
#77 4 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
35/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
csharp

研究方向

從 JTokenDifferentiator.CompareValues 開始,追蹤 config.Invoke 如何為每次值比較建立 JsonAssertionOptions。使用大型 JSON 文件和 Using callback 重現回報的速度變慢問題,然後比較變更 options 流程後的行為。在保留精度比較、避免重複的 builder 工作,並證明效能可接受後,即可視為完成。

由索引模型根據 Issue 內容生成。

描述

bug

To check doubles using precision when comparing JSON's, I am using the following options callback in BeEquivalentTo:

options => options.Using<double>(d => d.Subject.Should().BeApproximately(d.Expectation, 0.001))
  .WhenTypeIs<double>()

But it seems that this builder callback is being called for every value comparison.
JTokenDifferentiator.CompareValues contains:

using (var scope = new AssertionScope())
{
    actual.Value.Should().BeEquivalentTo(expected.Value, options =>
        (JsonAssertionOptions<object>)config.Invoke(new JsonAssertionOptions<object>(options)));

    hasMismatches = scope.Discard().Length > 0;
}

With the addition of the Using, a bigger json (MB's) goes from 200ms to +10s on my PC.

As a workaround, I replicated the behavior of the builder by accessing the userEquivalencySteps field on SelfReferenceEquivalencyAssertionOptions using reflection and inserting a custom IEquivalencyStep, instead of using the fluent API.
This brings it to 1s, which is acceptable for my use case.

Would it make sense to not call this options callback for every JSON value and build it once?
Or would adding API to add a custom IEquivalencyStep instead of the builder make sense?

主要語言
C#
星號
73
分支
30
PR 合併指標
30 天內沒有已合併 PR

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

相似的 Issue

更多 C# Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。