Forums: Index > Watercooler > How we fix slow articles

I have come up with a technique that will allow contributors to create arbitrarily complex templates without making page loads slower for other folks that may not be interested in the features provided by those templates. This "cache property" technique performs all the complex work on a subpage, then stores the results of the processing in a property or properties with the type "code". The main page simply loads the result property and is freed of the labor of recalculating it. A short technical description may be found below. Anyone interested in details please contact me.

One idea floated earlier was to validate values for consistency. Such a quality control page could be done this way. EG: does the page name or any of the values have all cap names, are the locations valid place names, do the dates make sense (eg child born to a woman that would have been 9 years old).

  • If any of these conditions are true, then the article is placed in hidden maintenance categories EG: articles with all cap names, articles with inconsistent dates, and so on.

If this "cache property" method is fruitful, it will mean that we don't have to choose between speed and features. We can have both. The cost is only that the data from time consuming templates will be out of date until the page is updated (either manually with a refresh, or via someone using Help:AutoWikiaBrowser to periodically refresh them.

In a nutshell...

  • Say page foo calls Template:LetsWatchPaintDry
  • Create page foo/someSubPage
  • Move your slow templates to that page and store the results in a property or properties of type code For instance:
    {{#set:DriedPaint={{LetsWatchPaintDry}} }}
  • Display the results on the main foo page with a normal show call, EG:

~ Phlox 17:53, October 10, 2009 (UTC)

This operation is largely complete, and folks should notice a marked increase in speed of displaying and saving main pages.
Time consuming templates should be placed on a /sensor subpage, and the only part on the main page (if any) would be a quickly executing template to move the results to the main page. An simple example would be to set a category based on a property set on the sensor page. A more complex example of this would be to display a table with the statistics on the percentage of ethnic groups represented for the person. All the main page would do is fetch the property with the calculated values and put them in a table. The math and lookups for all the values would take place on the /sensor subpage. (If anyone wants to do this particular template, you could quickly scan the ancestors property and use the ahnentafel values of all leaf most nodes to calculate the proper values. Of course, folks would have to start encoding and ethncity/ancestry group property in a uniform way, so it might be tough to get folks to save the data needed to make this work.)
There are more speed improvements to come, but probably this will have been the biggest increase in speed.
Anyone concerned about pages using showfacts templates that do not appear to be any faster, please contact me.~ Phlox 16:42, November 6, 2009 (UTC)