A few weeks back a Surfulater customer (lets call her Mary) was having a problem where Surfulater wouldn’t start. It turned out that if she closed Surfulater and then immediately started it again, it wouldn’t start. During the process of trying to work out what was causing the problem I asked if I could get a copy of the Knowledge Base Mary was using. Once I got that I was able to reproduce the problem and fix it. This particular database was reasonably large and it took a few seconds to save, while Surfulater was closing. When you close Surfulater it disappears from the screen straight away, however it is actually still running, saving your knowledge bases and cleaning up after itself. If you started a new copy of Surfulater before the first one had truly closed, things got messy, causing the new copy to crash. So to end this part of the story, that problem is now fixed.
But the real reason for this post is to tell you about an important improvement in performance that I’m just finishing up. For a while now some users have been asking for an option to display a summary list of articles in the content window when you select a folder in the tree, instead of displaying the full content of all the articles. The reason for this request is that if you have lots of articles in a folder, it can take a little while before they are displayed, and during that time you are locked out of doing anything with Surfulater. This was never an issue that overly affected me, as my articles always came up quickly enough. That all changed though when browsing through Mary’s Knowledge Base (with her permission of course). Surfulater could go off with the pixies for many seconds at a time and all you could do was twiddle your fingers and wait. So why was there such a dramatic difference to what I was personally used to? Well it is simply because Mary’s Knowledge Base contains lots of very big articles, and mine don’t. By very big I’m taking about articles with from 100 to 400 KBytes of text and often containing quite a few large’ish images. To display one of these articles, it may take say one second, which is ok. But when you have a folder with 30 like this, you could be waiting around for up to 30 seconds. If you clicked on the folder by mistake, then well that’s just too bad.
So where is this taking us. It was clear from seeing Mary’s Knowledge Base that something needed to be done. I could have provided the requested option of simply displaying a list of article titles when a folder was selected, but I’ve never felt particularly comfortable with that solution. This is because the ability to display all articles in a folder, in their entirety, is very important for some people. Also there is little point displaying a list of articles, when you already have that in the tree. So you may as well just display the folder, without any article information.
A better and more ambitious solution was to hive off the process of displaying articles, so that it wouldn’t interfere with Surfulater’s operation. To accomplish this I’m using what is called multi-threading, which in essence enables you to run multiple processes at the same time, instead of sequentially one after the other. This sounds simple enough, but in fact anyone who has worked on the development of a multi-threaded application knows only too well how complex it is. One overly simple analogy is to think about two (or more) people trying to drive the same car at the same time! The most complex aspect of multi-threading is ensuring the processes don’t get in each others way. If they do the program can easily hang, corrupt files or other resources.
These animations show the improvements I’ve been able to achieve. Both show me holding down the down arrow key to move through the tree. The left hand image shows the behaviour as it has been to date, without multi-threading. Notice that when the tree selection moves to a folder with a number of large articles it pauses waiting for the articles to be displayed. This is the dead time I’ve referred to earlier. The right hand image shows the new multi-threaded implementation, which you can clearly see is much more responsive. In fact it is faster than this image shows, as i was constrained by the recording software I used to create the animations.
| Â |
(You need to use IE to see the movies. For some reason they don’t appear in Firefox!)
The results are clear. You can now click on a folder with lots of large articles and continue working, without having to wait for all articles to be displayed. There may still be a short pause, depending on the size of the article currently being processed. This is due to constraints we have on what we are able to do in our background thread.
For the folks that have in the past requested an option to not display articles when a folder is selected, I’d like to know if this new multi-threaded implementation removes that need. And of course I welcome everyone else’s comments as always.
The plan is to have this available in the next release V1.99.0.0, which should see the light of day early next week, if not sooner.
 