DoWikiRequest

Back up to Functions, or to UseModWiki/DeveloperQuestions

This is the "main" function. It is called at the end of the script file

It does several things, and I will fill in the details as I figure it out over the next few hours.

1. It checks to see if we want to read in the config file, and if so, we do read it in.

2. It runs InitLinkPatterns, which does two important things... (a) Initialize the complicated regular expressions used to find links in the text and (b) set up the field separators that we use to read in the .db files.

3. Then it runs the code to handle the user's request:

• The code first tries to use the HTML cache with DoCacheBrowse (if that feature is enabled, which it isn't by default).
• If the cache fails (or is not enabled), the code evaluates BrowseCode [how? - DeferredCompile] (which loads in most of the common page-browsing code), then runs DoBrowseRequest. If that comes back as true, we're done.
• Otherwise we eval OtherCode (which handles editing and less common functions) and we run DoOtherRequest.

The reason for this complication is to avoid compiling a lot of the wiki code when the wiki is used as a CGI script. If the cache handles the request, one can avoid loading CGI.pm and most of the wiki code. Simple browsing requests can avoid compiling the editing, searching, and other less-frequently used functions. Most of the savings are in the cache case--I've sometimes considered removing the browse/other distinction. --CliffordAdams

---

My tests show a small further delay in editing compared with viewing a page, when viewing pages soon after the cache is switched on. If the cache has been running since wiki was installed then I think most pages are already in it (because every page gets cached when it is displayed at the end of the create/edit process).

But actually, the optimisation could be improved further. The biggest wasted compiler effort in the current model occurs when you do an "other" request that does not use the "browse" code at all.

For example, setting up for edit should be the fastest thing in the system - check if user is allowed to edit, send out a pretty standard form (only customisations are version-related stuff and warnings if there is conflict), and the text is provided in wiki format so none of that HTML conversion code is ever run.

Another example is indexing the site - as far as I can see there is no need for (most of) the browse code to run that.

The delay occurs because the current DeferredCompile strategy is to attempt to run each possibility in turn.

A faster strategy would be essentially to move the switch for DoOtherRequest and DoBrowseRequest into DoWikiRequest, and only compile further code after we know what we've got.

Very approximately it would look like this

if (DoCache) {
  return
}
&GetParam

if (IsEdit) {
    compile edit set-up code
    Do Edit
} elsif (IsBrowse) {
    compile browse code
    DoBrowseRequest
} elsif (xxx) {
    compile xxx code
    DoXXXRequest 
} else {
    die "unknown request"
}

where xxx could be a single option or as many options bundled together as you like.

The further detail is that within the DoEdit code, at the point it becomes apparent that the browse code will be needed, it will have to be compiled (at present you safely rely on the fact that it has always been compiled before you get there).

Three further points

1) after eval $code I recommend a $code=""

• if you accidentally recompile it doesn't cost anything the second time
• it frees up some memory

2) depending how keen you are to divide the code up, each of those compile steps could be to compile more than one code segment, eg eval $foo.$bar if that item needs both foo and bar code segments.

3) the order I have given is probably the best for a system with cacheing and the majority of pages in cache. Most requests being handled by the cache, the next most frequent request is to edit, and only then (should) come having to re-generate a browse page from wikitext.

None of the above is a request for further work - just some ideas on how to take it forward if you or anyone else happen to feel like working on this.

--RiVer

PS - a third strategy is outlined on the WikiPatches/CiwiNi page