Configuration of IJsonAssertionOptions slows down comparison a log
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- À l'abandon
- Stack technique
- csharp
- Domaine
- performance, testing
Piste de recherche
Commencez dans JTokenDifferentiator.CompareValues et suivez la manière dont config.Invoke crée JsonAssertionOptions pour chaque comparaison de valeurs. Reproduisez le ralentissement signalé avec un document JSON volumineux et le callback Using, puis comparez le comportement après avoir modifié le flux des options. C’est terminé lorsque la comparaison de précision est conservée, que le travail répété du builder est évité et qu’une performance acceptable est démontrée.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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?
- Langage dominant
- C#
- Étoiles
- 73
- Forks
- 30
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Issues similaires
-
Bug pulumi/pulumi
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
activescott/lessmsi#306 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
HTML sitemap lists unpublished pagesPeut-être pris @KrzysztofPajak l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
grandnode/grandnode2#883 ·
Les mainteneurs répondent en général sous 1 jour
-
[Bug]: `winapp ui <command> --on sandbox --help` starts sandbox setup instead of showing helpOuvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
Les mainteneurs répondent en général sous 1 jour