Today I've been working on how WSN performs, especially with large pages and especially when not using query caching. Specifically, when I was trying to show 132 articles at once on a page at scripts.webmastersite.net/...nistrative-tasks/switches/ it was taking as long as 30 seconds to load.

Delving into that, I found several culprits. First, when WSN is configured to only allow one vote per person per listing, there was a query that checks whether the viewer has already voted on a given listing. This was running 132 times for the 132 articles, so I changed it to pre-cached a list of all listings voted on by the viewing member (1 larger query that runs a lot faster than 132 small queries). Then I found a similar situation with the saved listings system, it was running a query on each article to see if we've saved that article -- so I cached that with a single advance query too. That's 262 queries eliminated and twice as fast a page load, but still not fast enough.

Next, I noticed that it was querying category #5 once for each article displayed. Turns out this was a parent being queried for {LINKCATNAMEWITHNAV} navigation which is shown in search results but still in the link bit template all the time even when conditionalized out. I made that method cache the categories so it only queries each category id once. That saved another 131 queries and 4 seconds.

After the above, the article processing in the middle of the page was reasonably fast -- but the page as a whole was still unacceptably slow. This turned out to be mostly because of some inefficiencies in processing huge pages (132 articles is a lot of text, even when it's just listing bit stubs). The funcreplacements() call which replaces the {FUNC_ generic function template calls was taking 3 seconds to run. This was because of hundreds of {FUNC_SHOWICON[edit]} calls running redunantly for every article. I've optimized that away so it only runs the showicon function on each icon once.

Applying the same optimization theory (removing all non-unique results from the preg_match_all()ed array before processing it) to settingsreplacements helped further. Then when I was about to apply the same to objectreplacements I discovered that I'd already done that a long time ago, and the new function I'd written for it just now was a duplicate of a function I'd written before for objectreplacements, heh. So I went back and changed settingsreplacements and funcreplacements to use the same uniquematches function that objectreplacements was using. Also applied it to switchreplacements and conditionals processing.

The end result? WSN 10.3.30 beta 1 is faster no matter what you're doing with it, and drastically faster if you've got long pages with lots of items on them. Still rather slow on that 132 article page though, so I'll keep working on it and see how much more time I can shave for beta 2.

Note that these benefits won't be as apparant on most page loads for most people, because you're normally seeing a query-cached version. I have query caching disabled on the manual for complex reasons (some tables shared between all the different script manuals creates issues for query caching). Your worst case page load times will improve a lot though.