Didn't JENKINS-18721 resolve the performance issue sufficiently?

Looks like JENKINS-18721 made some improvements, but getItems still looks to go through all jobs twice: once in includeItems, once in the loop to translate names into items.

Basically the issue is that instead of doing the obvious thing—looking up explicitly-specified names using the method that exists for that purpose, then scanning recursive items whose relative name match the regexp and adding those in—the view is scanning recursive items, adding them to the name list, then going back and scanning recursive items again and collecting those whose (relative) names match the list. And the job filters are reported to be called with the wrong arguments: the direct children of the folder.

JENKINS-20143 should have fixed the behavioral issue with recurse (though there is no test yet), but the poor implementation remains (and the code is even more bloated with the new expand method which yet again traverses the job hierarchy).

Worth investigating whether the three existing fields in ListView controlling job inclusion—jobNames, includeRegex, and statusFilter—can all be migrated to be ViewJobFilter implementations. (recurse cannot, since it determines the all parameter to filters.)

A great side-effect of making jobNames into a ViewJobFilter would probably be that jobs are no longer automatically added to the view the user was in when she created the job. Which is really annoying if you have views with very specific, computed contents.

jobs [would no longer be] automatically added to the view the user was in when she created the job

Right, unless you actually had one of the new filters configured, which I guess would happen only if jobNames were originally nonempty. A good point.

Noting that change ([PR-4466|https://github.com/jenkinsci/jenkins/pull/4466]) results in Views with the StatusFilter set being removed when upgrading from <2.239 to >2.239.

Related issues: JENKINS-62661, JENKINS-63786.