Performance compared to native validation

[knobel-dk]

Native Laravel validation performance is well-known to be slow due to Arr::dot, see laravel/framework#49375

I was exploring this package hoping that it would be more performant but I get these results:

class IdData extends \Spatie\LaravelData\Data
{
    public function __construct(
        public int $id,
    ) {
    }
}

class ArrayData extends \Spatie\LaravelData\Data
{
    public function __construct(
        /** @var IdData[] */
        public array $array,
    ) {
    }
}

$array = array_map(fn (int $id) => ['id' => $id], range(1, 5_000));

\Illuminate\Support\Benchmark::dd([
    fn () => \Illuminate\Support\Facades\Validator::validate(['array' => $array,], [ 'array.*.id' => 'required|integer', ]),
    fn () => ArrayData::validate(['array' => $array])
]);

array:2 [
  0 => "188.543ms"
  1 => "13,456.497ms"
]

Am I doing something wrong?

(And, needless to say, but thank you so much for your contribution to the ecosystem ❤️ )

[knobel-dk]

Placing these classes in App\Data and running php artisan data:cache-structures give a tiny, tiny improvement of a few hundered ms

[rubenvanassche]

I think as a rule of thumb, never use data validation for really big collections 😅

The thing is that we use NestedRules for each data object and those are tailored for every data object since one can always change depending on the values provided (see the rules method). Technically we could add some smart caching here and there which could speed up the process (when there's no rules method we kinda know the rules will probably be the same for every object).

But adding such a thing is a lot of work and requires really good testing in order to break nothing, something on my long list for data v5 but that will probably take some months to even get started on.

[knobel-dk]

Thank you so much for a great reply. Just one question:

I think as a rule of thumb, never use data validation for really big collections 😅

Any ideas on how to validate a really big collection? 😅

[rubenvanassche]

In Flare we've created a validator per item that was surprisingly faster than expected, otherwise manually writing out rules in PHP or searching for another library?

[cyppe]

@rubenvanassche Do you have some details/example of how you mean with "a validator per item" so I can use your approach as inspiration. As I also have performance issues with the validator so looking for some alternative approach and as you know this package better than anyone it would be interesting to know how you worked around it.

[knobel-dk]

@cyppe

An update from me as the OP.

I ported this part of my app to Spring Boot with Kotlin and coroutines for multi threading. I saw a 30x performance gain and am happy.

My Laravel codebase is highly optimized and I love Spatie's work and Laravel at large but newing up type-safe object with validation seems to be one of those problems for which there are better tools.

Here's another example of single-threaded PHP/Laravel not being suited for this:

laravel/framework#49375

[cyppe]

Im on a mini-mission to try to fix the performance issues.

I started with improving Arr:dot with the hope it would resolve laravel-data package validation automatically. But it did not do any major benefit, but the Arr:dot improvements for regular validations is still huge so it's not wasted time and will help with all kinds of laravel validate methods. It actually got merged already: laravel/framework#55495

But again - it did not move the needle very much for laravel-data as I hoped. So I am working on this PR that seems to work good, but any feedback is welcome.

It's for cases where there is no rules() method in the Data objects, as they can have runtime conditions hard to improve this way.

#1005

Of course extra interested in @rubenvanassche feedback.

[knobel-dk]

Impressive performance gains on the Laravel PR.