Joey Hess [Sun, 17 Nov 2013 20:37:18 +0000 (16:37 -0400)]
search: Added googlesearch option, which makes it search google rather than using the internal xapain database. (googlesearch plugin is too hard to turn on when xapain databases corrupt themselves, which happens all too frequently).
Joey Hess [Sat, 16 Nov 2013 21:26:20 +0000 (17:26 -0400)]
Added only_committed_changes config setting, which speeds up wiki refresh by querying git to find the files that were changed, rather than looking at the work tree. Not enabled by default as it can break some setups where not all files get committed to git.
Joey Hess [Sat, 16 Nov 2013 16:48:07 +0000 (12:48 -0400)]
Optmised loadindex by caching the page name in the index.
I have benchmarked the pagename() call this avoids taking up to 2 seconds
for a loadindex in a large wiki. The total loadindex for that wiki was
6.46s, so this is a significant improvment.
Even on a smaller site, this reduces the refresh time from 1.69 to 1.52
seconds.
The only breakage risk here is that pagename() can change the page name
it calculates due to setup changes. But in the case of a setup change, the
whole site is rebuilt. So the cached page name is not used in that
case.
Joey Hess [Sat, 16 Nov 2013 16:43:46 +0000 (12:43 -0400)]
remove test for page state saved for disabled plugin
My change did cause this state to be retained. I hope this is not a
problem.
Afaik, plugins test if they were disabled before by looking at the toplevel
plugin state, not the per-page plugin state. So the only remaining problem
might be
a) A plugin is disabled but its state keeps being saved. Which is not
ideal, perhaps, but the large speedup of my optimisation seems worth it.
b) A plugin might have been enabled, be disabled, and get re-enabled, and
see old state from before. I don't see how this would be different from
the plugin seeing any other old state, though, so hopefully no breakage.
My optmisation looks a little more risky, but I still hope I can keep it.
Joey Hess [Sat, 16 Nov 2013 16:28:01 +0000 (12:28 -0400)]
Fixed unncessary tight loop hash copy in saveindex where a pointer can be used instead. Can speed up refreshes by nearly 50% in some circumstances.
I *think* this is ok, at least it results in close to the same index being
saved as before. The difference is that plugins that have a pagestate of {}
have that recorded this way, while with the tight loop, the key for the
plugin in not copied in that case. I cannot see how this could matter.