There is a performance and logic duplication issue with serving WFS 1.1.0 GetFeature requests with GeoJSON output format.
GetFeature.run() calculates the total number of features that the query matches (for paging purposes)
GeoJSONGetFeatureResponse.getFeatureCountFromWFS11Request() counts the number of total features again (to include the full number of features in the GeoJSON reponse)
There are two issues with this: first of all it is suboptimal to count the features twice. This is especially problematic with complex data sources (for example cascaded WFS stores, JDBC stores serving data especially from non-trivial objects). The second issue is that this implementation requires duplicating query and filter logic in the response class, which is the wrong place in the architecture and message flow.
For WFS 2.0.0, the total number of matching features is retrieved in the response writer via FeatureCollectionResponse.getTotalNumberOfFeatures(). This feels like a much better pattern but some reason, this method just returns null for WFS 1.0 / 1.1.
A possible fix for this would be to make this method into a lazy getter and make sure the same lazy mechanism is used within the execution of the query itself, as the query requires the number of features to do paging etc. This would both optimize the execution and fix the architectural issue.
(modified and reposted from a message geoserver-devel on June 11th 2015)