Configuration of IJsonAssertionOptions slows down comparison a log
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- csharp
- Área
- performance, testing
Línea de trabajo
Comienza en JTokenDifferentiator.CompareValues y sigue cómo config.Invoke crea JsonAssertionOptions para cada comparación de valores. Reproduce la ralentización informada con un documento JSON grande y el callback Using; después, compara el comportamiento tras cambiar el flujo de opciones. Se considera terminado cuando se conserva la comparación de precisión, se evita el trabajo repetido del builder y se demuestra un rendimiento aceptable.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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?
- Lenguaje dominante
- C#
- Estrellas
- 73
- Forks
- 30
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
owasp-dep-scan/dosai#79 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
pyrevitlabs/pyRevit#3730 ·
Los mantenedores suelen responder en 1 día
-
bug component/other
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
umbraco/Umbraco.AI#511 ·
Los mantenedores suelen responder en 1 día
-
sev:L
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
Systemorph/MeshWeaver#6233 ·
Los mantenedores suelen responder en 1 día
-
[Bug]:Abiertobug needs response
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Adyen/adyen-dotnet-api-library#1874 ·
Los mantenedores suelen responder en 1 día