TryValidateModel is slow with large arrays

[CommonGuy]

The code

TryValidateModel(model);

is very slow when i pass a model with huge arrays. My model looks roughly like this:

public class MyModel
{
    [Required]
    public string Id { get; set; }
    [Required]
    public byte[] Data { get; set; }
    [Required]
    public Dictionary<string, string> Metadata { get; set; }
}

If Data is only a few KB, everything is fine. However, if Data is filled with ~5MB, the validation takes nearly 2 seconds on my machine. I'm using .NET Core 1.1.

Of course, I could disable validation for MyModel and validate the properties myself... But I still think this is a bug, since I could not find any information on this topic (e.g. not to use validation on large arrays).

Note: Removing the [Required] from Data doesn't make any difference.

[kichalla]

This bug was actually fixed recently and is available in nightly builds. ce53675
With this commit you can decorate the property with a ValidateNever attribute.

Meanwhile you could update the MVC options to exclude byte array from validation (this effects the entire app but I can't see why we do not do this by default. @dougbu ?)

options.ModelMetadataDetailsProviders.Add(new SuppressChildValidationMetadataProvider(typeof(byte[])));

[kichalla]

Correcting my previous comment :-)...We don't know if this a bug yet but there is a new way (through ValidateNever) through which you can selectively disable validation.

[CommonGuy]

Yes, I've read about ValidateNever and it looks cool. But I think of it as a workaround in this situation. I think it is dangerous to globally exclude byte arrays from validation...

By the way, validation is also very slow for lists with a few thousand entries. If I change my model to

public class MyModel
{
    [Required]
    public string Id { get; set; }
    [Required]
    public List<byte> Data { get; set; }
    [Required]
    public Dictionary<string, string> Metadata { get; set; }
}

the problem still exists.

[rynowak]

@kichalla - using [ValidateNever] is a workaround - we need to be smart enough to do this by default when there's nothing to validate.

[Yves57]

Isn't it something like:

...
else if (IsEnumerableType && ElementType.GetTypeInfo().IsPrimitive)
{
     _validateChildren = false;
}
...

in DefaultModelMetadata.ValidateChildren?
Of course, with this kind of modification, the validation time decreases to nothing.

[dougbu]

@Yves57 it would be similar to what you've got.

Should also confirm no validators are configured for ElementType and it might be better to do it in an IValidationMetadataProvider implementation. While unusual, primitive types can certainly have associated validators e.g., an IValidationMetadataProvider implementation could add [Range(0, 20] to the byte metadata.

Put another way, your suggestion is a good way to avoid recursion through the metadata to find validators. Still need to look for those validators.

[rynowak]

Looking at this issue again, this is definitely something we should profile and try to improve.

Secondly, we need to hold on to this piece of design feedback: it should be possible for model binding to determine that a graph is a 'no-op'. Today we can't/don't due to that due to the flexibility to the validator providers have in MVC, and we're contributing a lot to global warming. We should make sure that any new validation system can determine when not to explore an object graph with greater vigour.

[pranavkm]

Moving this to 3.0

[pranavkm]

Back to 2.2.0-preview3