A user of ParameterFilter had an unresponsive UI; the thread dump revealed several HTTP handling threads (e.g. GET /) busy as follows:

at hudson.views.ParameterFilter.matchesRun(ParameterFilter.java:142)
at hudson.views.ParameterFilter.matchesBuildValue(ParameterFilter.java:129)
at hudson.views.ParameterFilter.matches(ParameterFilter.java:97)
at hudson.views.AbstractIncludeExcludeJobFilter.doFilter(AbstractIncludeExcludeJobFilter.java:68)
at hudson.views.AbstractIncludeExcludeJobFilter.filter(AbstractIncludeExcludeJobFilter.java:57)
at hudson.model.ListView.getItems(ListView.java:170)

While I am not sure whether matchAllBuilds was set in this case, inspecting the code of matchesBuildValue shows that it could be quite expensive when run against a job with hundreds or thousands of build records. This is doubly true in Jenkins 1.485+ where build records are lazily loaded, so doing a search like this could cause a great deal of activity to occur loading build.xml from disk, increasing memory as well—and soft reference eviction could mean that this needs to be done repeatedly.

Would be better for matchAllBuilds to be replaced with an int limit >= 1, so that users could put a cap on how many builds would be consulted before giving up.

It may also be useful to cache information about matches, since parameters of build records should be immutable once the build is complete.