On Thu, Mar 21, 2013 at 6:40 PM, Asher Feldman <afeldman(a)wikimedia.org>wrote;wrote:
Right now, varying amounts of effort are made to
highlight potential
performance bottlenecks in code review, and engineers are encouraged to
profile and optimize their own code. But beyond "is the site still up for
everyone / are users complaining on the village pump / am I ranting in
irc", we've offered no guidelines as to what sort of request latency is
reasonable or acceptable. If a new feature (like aftv5, or flow) turns out
not to meet perf standards after deployment, that would be a high priority
bug and the feature may be disabled depending on the impact, or if not
addressed in a reasonable time frame. Obviously standards like this can't
be applied to certain existing parts of mediawiki, but systems other than
the parser or preprocessor that don't meet new standards should at least be
prioritized for improvement.
Thoughts?
As a features product manager, I am totally behind this. I don't take
adding another potential blocker lightly, but performance is a feature, and
not a minor one. For me the hurdle to taking this more seriously, beyond
just "is this thing unusably/annoyingly slow when testing it?", has always
been a way to reliably measure performance, set goals, and a set of
guidelines.
Like MZ suggests, I think the place to discuss that is in an RFC on
mediawiki.org, but in general I want to say that I support creating a
reasonable set of guidelines based data.
Steven