I'm a diehard WikidPad user, I love it, love it, love it. WikidPad2_3beta13_01 on Linux (at home) and Windows (at work).
I hit productivity walls because WikidPad takes so damn long to parse
pages I open, with ^O or following a [wikilink]. WikidPad is not usually
unresponsive at these times, which is a great credit to
the developers, but until I can see what words in a new page already
lead to other topics, I can't compose my thoughts about creating new
topics vs adding to existing
I have a couple of original_sqlite wikis, the largest about 6200 topics and 12 MB including the index .sli file (but not the full text indexes; whoa, that's another 35 MB).
Python has a problem with multiple threads and I have fixed that by constraining it to a single CPU and thread. That produces a significant performance gain, which I suspect will affect any modern system. Unless you fix this, WikidPad performs slower on any multi-thread system than any single-thread system, so I reckon it should be integrated into the WikidPad install images...
At home I have an AMD FX-4100 with 3600 MHz per core; at work a lower MHz but a more recent Intel architecture. Disk access doesn't seem to be a problem; at home and at work I have SSD drives, and neither suggests that disk access or free RAM limits performance.
I can't help thinking that maybe the parsing algorithms could use some optimisation. Even a single thread on a modern CPU should not take so long to parse a couple of kb of text against a SQLite index of defined wikiwords.
I am not a Python developer, but I value WikidPad mightliy. Is there a Python developer out there who can take on a challenge to significantly improve WikidPad performance in that key area. I will offer a 'bug bounty' or performance bounty- who will take it on and how large does the bounty need to be?
Best,
Graham