I agree. It would be good if there *were* a technical measure to stop fair use violation though. Perhaps if it were to check the page when it is saved (like the spam black list) it would be viable. .. That actually leads me to think: does the spam black list extenstion have a "block this link except on this page"? /me also thinks that wikipedia-l is not IRC, alphax

Yoni Weiden wrote: Paste it into a text editor. But it's not a limit, it's a recommendation. I'm working on the (naive?) assumption that sysops care about performance too. It's stored in the message cache, a single blob containing pretty much everything in the MediaWiki namespace. This blob is loaded and unserialized on every request. Currently on enwiki it is about 280KB. I wouldn't want to see this single feature take up a significant proportion of it. Also there's the fact that this is implemented on the page view side, so it's called much more often than the spam blacklist, which only filters saves. The spam blacklist would be far too slow to work on the parser side. wfIsBadImage is currently profiling at 0.8ms per call, wfSpamBlacklistFilter is taking 505ms per call (it's very badly optimised at the moment). -- Tim Starling

On 9/25/06, Angela <beesley(a)gmail.com> wrote: Hey, wow. Thanks. :) I was going to raise that point... but I figured I'd catch Tim in IRC. In any case, I agree here.. the issue is that for every valid case where it might be good to be performance minded there are 10 other cases where people will use uninformed performance oriented arguments to support whatever policy measure they prefer... The end result is a lot of silly actions in the name of performance .. or a lot of needless performance questions. :)

Gregory Maxwell wrote: Sure, using poorly informed performance-oriented arguments to win whatever argument you're having is a bad thing. But it's not an issue when I am telling you EXACTLY WHAT TO DO. In fact, I've been thinking about writing some general guidelines for template performance optimisation that editors can follow. Editors can do quite a lot for the performance of the site, if their efforts are properly informed. I've even edited articles myself, for the sole purpose of making them render faster. Others could do the same. -- Tim Starling