Configuration of IJsonAssertionOptions slows down comparison a log
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- csharp
- Domínio
- performance, testing
Direção de pesquisa
Comece em JTokenDifferentiator.CompareValues e rastreie como config.Invoke cria JsonAssertionOptions para cada comparação de valores. Reproduza a lentidão relatada com um documento JSON grande e o callback Using; em seguida, compare o comportamento após alterar o fluxo de opções. O trabalho estará concluído quando a comparação de precisão for preservada, o trabalho repetido do builder for evitado e um desempenho aceitável for demonstrado.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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?
- Linguagem predominante
- C#
- Estrelas
- 73
- Forks
- 30
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Issues semelhantes
-
Bug pulumi/pulumi
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
activescott/lessmsi#306 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
HTML sitemap lists unpublished pagesTalvez já em andamento @KrzysztofPajak assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
grandnode/grandnode2#883 ·
Mantenedores costumam responder em até 1 dia
-
[Bug]: `winapp ui <command> --on sandbox --help` starts sandbox setup instead of showing helpAbertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
Mantenedores costumam responder em até 1 dia