If you are new to this program and are trying to familiarize yourself with the basics or are otherwise trying to simply get up and running, then I implore you, skip this section entirely.
Most modern computers have multiple processors and/or have processors which have multiple cores. For our purposes we need not concern ourselves with the distinction between these two concepts. The important point is that both of these features enable computers to perform true parallel processing, i.e., they can perform multiple operations at once. One obvious advantage of parallel processing is that time-consuming tasks can be accomplished more quickly.
Keith's Image Stacker exploits parallel processing through multi-threaded task division for many of its basic operations. Specifically, most operations which are performed on a set of frames in the Clips Window can be performed in parallel by dividing the set of frames up into multiple subsets, one per thread. The GUI provides a fairly simple interface for controlling how threads are used. When used properly, multiple threads should enable you to vastly speed up the program. The menubar has a Threads menu, which in turn has two sections. In the main section you can specify how many threads the program should use for operations which can be performed in parallel. The question then arises, how many threads should you specify? The basic rule of thumb is simply to assign about one thread per core on your machine. This assumes that you do not have any other processor-heavy programs running at the same time. So if you have a single processor dual-core machine, the rule of thumb would prescribe two threads. If you have a dual processor, quad-core machine, then eight threads would be the suggestion, and so on. The basic logic here is that each core should have a thread to work on so it is kept busy instead of sitting idle without any work to do.
However, in some instances, there is a further benefit to be realized by assigning as many as two threads per core. In other words, some further speedup may be achieved by assigning up to two threads per core. The reason why this can be beneficial is that a thread might stall while it is waiting for data to be loaded from RAM into a low-level cache. While waiting, the core in question can load the second thread and do useful work instead of sitting idle. This same benefit can, on occasion, reach past two threads per core, but just as likely, the overhead of handling numerous threads can actually cause a decrease in overall performance if threads are abused (a task that takes sixteen seconds with four threads might take twenty seconds with eight threads on the wrong machine!). Therefore, it is recommended that you not specify more than two threads per core. It should be noted that the benefit of going from one thread per core to two is far less significant than from going from one thread overall to one per core. That is where the main speedup will be achieved.
NOTE: The number of threads you wish to use will be saved when you quit and restart the program, so you shouldn't need to reset this setting every time the progam starts up.
A second setting is also provided from the Threads menu. This setting indicates whether the program should make sure the display stays synchronized to the progress of the various threads during a long multi-threaded operation. This synchronization mainly pertains to the thick cyan border that is used to highlight the current working clips and to redrawing the updated clip of a frame in the Clips Window immediately after it has been modified. These methods of synchronization require some threads to pause briefly and this can slow down the overall operation slightly. If you do not find such synchronization to be crucial and are more interested in the fastest possible throughput, you might consider disabling display synchronization.