https://bugzilla.wikimedia.org/show_bug.cgi?id=19262
--- Comment #31 from MZMcBride <b...@mzmcbride.com> 2011-09-03 02:34:02 UTC ---
(In reply to comment #29)
> In fact, there's an entire essay on en.wiki: "Wikipedia:Don't worry about
> performance"
>
> Clearly this mindset is now outdated. Perhaps you or Brion could post about
> this issue on the Wikimedia Blog so that we can start to change this mindset
> and get people working on template optimization.
That's most certainly not the solution. This can't be stressed enough. Tim and
I have discussed this (though he comes down on your side still, I think, or did
at one point).
The scope of Wikimedia projects is the dissemination of free educational
material. When you make it the job of wiki users to debug complex
wiki-templates and try to fine-tune them, it's a very bad and very undesirable
situation.
Users should not be worried about performance, by and large. They certainly
shouldn't be concerned that they're using too many calls to citation templates
(of all things!). We want users to be encouraged to cite information and build
content. That's the goal. We want to discourage mindless "optimizations"
(without any real debugging tools) that users will inevitably and invariably
make in the name of fixing a system that they didn't break and that's not their
responsibility to maintain.
(In reply to comment #28)
> This isn't really a single issue. Every page is going to have a different
> specific reason for taking a long time to load.
Err, prove it. The pages that I've seen that are slower all have the same root
cause: too many calls to particular types of templates. Citation templates are
the biggest issue, but the coord(inates) family and the convert family have
also caused problems in the past.
> I think more sandbox testing like what MZMcBride did (see comment #2) would be
> very valuable to isolate specific templates that are ripe for optimization.
It's valuable when there's a dearth. But at the moment, finding large pages
that take an excessive amount of time to load/render/parse is easy. And the
solution(s) are already known (as Domas would say, this is very low-hanging
fruit from an optimization standpoint). It's a matter of implementing the
solutions (which I guess Tim and Victor are working on).
(And, going forward, users ideally won't even have a real concept of templates
outside of "those things that make wiki-editing more standardized." We want to
get users away from thinking about "{{cite web}}" or "{{coord}}" or anything
like that. That's echoing what Brion and many others have said, especially as
work on the new parser ramps up. Trying to get users to care about these
templates and then trying to get them to make them faster is a step in the
wrong direction.)
> I'm not sure if this particular bug is going to be valuable to keep open.
> It's
> not specific enough to ever be closed.
This bug is fine. When there is a better system (or systems) in place that make
the pages load faster, this bug can be closed. Just because a bug is difficult
or is going to likely remain open for a long time doesn't make it any less
valid. There's certainly something problematic and actionable here.
(In reply to comment #30)
> When I first posted this, it was taking 35 seconds or longer. It got worse.
> But I checked it today on IE and Firefox and it was fast - about 2 seconds.
> Has something been fixed?
Sounds like you just hit cache. (Or I suppose it's possible someone drastically
reduced the number of template calls in the page you're looking at.) Do you
have a particular example page/URL? Have you tried with ?action=purge appended?
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
