Performance regression due to additional count call

[bwaidelich]

Calling count() on an object can be very "expensive", especially if it's a QueryResult-object with a large set of records as a SELECT COUNT(*) can be very slow with a lot of records (pagination, i.e. a limit/offset won't make a difference).

In my case it's more than an order of a magnitude difference to render 30 records at once (0,042s vs 0,76s)

The bottleneck comes with the newly introduced AbstractViewHelper::isValidType():
It does some (possibly dangerous and expensive) operations on the given arguments, including count and getFirstElementOfNonEmpty() on collection values.

Previously we only checked whether the type matched the argument definition

BTW: There's another possible side-effect in the argument validation: getFirstElementOfNonEmpty() actually resets any collection argument

[bwaidelich]

(reference: neos/flow-development-collection#759)

[bwaidelich]

FYI: A quick fix is to replace

} elseif (count($value) > 0 && substr($type, -2) === '[]') {

by

} elseif (substr($type, -2) === '[]' && count($value) > 0) {

in AbstractViewHelper::isValidType()

Which makes sense anyways IMO - but obvously that's just a fix for some of the cases

[NamelessCoder]

I'm thinking we may be able to drop the count() entirely in the case above. I'm looking into that right now.

[NamelessCoder]

#245 could be a way to deal with the count() in argument validation. It does however slightly change the verdict for non-empty arrays/iterators where the first value is null, for whichever reason. Such cases are now considered valid (taken as reasonable indication that the subject was empty, thus valid).

[bwaidelich]

Great, I like!