Notice that the revised Image application uses aft additional Form with a Progress Bar control, which shows the progress of the. algorithm. The ProgressBar control’s value is set after each completion of the inner loop. which processes one line of pixels. Since the image on the PictureBox control isn’t updated in real time, the progress bar provides some feedback to the user. so that they know how the processing is going. At each step, the Progress Bar control’s value is updated with the statement:
Form3.ProgressBar1.Value = i * 100 / (y – 1)
The outer loop’s counter is i and it goes from 1 to is the vertical resolution of the image). The ProgressBar control’s Min property 0 and its Max property is 100, and it’s the same control that’s used to indicate tho progress of an if ‘age .when it loads. Figure 12.3 shows the Image application as it processes an image.
To appreciate the full effect of the optimization effort, you should load the Image applications from the CD, check all the advanced optimization switches in the Advanced Optimizations dialog box, and compile the images to native code. Then, run the executables and time the three versions of the application to see the effect of the various optimization techniques. Feel freeto further customize the application and see if you can make it any faster. Most likely, further optimization isn’t going to, show such apparent improvements .
Optimizing the DirMap Application
Another useful application in this book that could use some optimization is the Dir ap application of Chapter 11.This application iterates recursively through the files of a given folder (or drive) and creates a list like the one shown in Figure 12.4. The DirMap application, which uses a recursive function to scan a specific folder and its subfolders, is described in detail in Chapter 11.
The OiiMap application can scan a small folder (one with a small number of subfolders), but if you attempt to scan an entire drive, it will deteriorate rapidly. The DirMap application can scan the Program Files folder on my system in 25 seconds. This specific folder contains 2,673 files in 186 subfolders. By contrast, my’main hare disk contains 12,363files in·l,054 folders, and it takes the original DirMap applicatior 374 seconds to scan it. This is an awful lot of time for a rather simple operation. As you can see, the program gets disproportionately slower as the number of folders, files increases. You will also notice that the number of processed files, which is displayed on the Form and updated every time the program visits a new subfolder, increases quickly initially and not so quickly as more and more files are processed.
As you can guess, the source of the delay is the line that appends new data to the DirStructure string variable. As we mentioned earlier in this chapter, manipulating long strings with Visual Basic is very costly in execution time. To verify that the source of the delay is the manipulation of the DirStructure variable, comment . out the lines that append a folder/file name to the variable DirStructure. These lines are shown next:
The revised application scans the same hard disk in approximately 75 seconds (versus 374 seconds). These two lines are really slowing down the application, especially when it scans large drives or folders. One of the simple optimization tricks we mentioned earlier in this chapter is to avoid manipulating long strings. The DirMap application builds the list of folders and files as an RTF string, which is then assigned to the RTFText property of the RichTextBox control. This string can become quite long, and each time we add a new folder and file name, this string grows. The longer the string, the more time it takes to append characters to it. For a fair-sized folder, like the Program Files folder on my system, the contents of the RichTextBox control exceed 140KB.Considering
the string variable experiments we carried out earlier in the chapter, you can easily see that the manipulation of this variabr ~ responsible for most of the application’s execution time.
Clearly, we must limit the size of the string that holds the contents of the Rich TextBoxcontrol. To avoid a very large string, we can build it piecc by-piece: append a number of file and folder names to an intermediate string variable, and every time this variable’s length exceeds a threshold, append it to the long string variables, reset the intermediate variable to an empty string, and continue. The core of the DirMap application’s code-is the ScanFolders() subroutine, which is shown here:
The variable that holds the Rl’F string to be displayed on the RichTextBox control is the DirStructure variable and it can become extremely long. We must use another variable, the tmpDirStructure variable, whose length we’re going to keep under control. Every time the tmpDirStructure variable’s length exceeds a threshold (5,000 characters or so), we’ll append it to the Dirbtruclure variable and reset the tmpDirStructure variable, The process will.continue for as long as the program is running
To do this, WE must first replace the line:
A threshold value of 8,000 characters is a reasonable compromise. You can experiment with this setting and see for yourself that very small or very large values are actually bad choices. A very small value means that the body of the .previous If. Then structure is executed very frequently, and in effect, diminishes any gain from not allowing the DirStructure variable to grow too long. Avery large threshold gets us back to the situation we wanted to avoid in the first place.
When the ScanFolderf) subroutine is called for the last time, we must move the contents of the temporary variable to the actual variable. This takes place from within the Click event’s handler of the Command button on the Form, after the . ScanFolderO subroutine is called. The revised handler is shown next (the new lines . are underlined):
The optimized DirMap application is stored in the OPTIMZD folder on the CD, and it’s identical to the original DirMap application, except for the changes explained in the previous paragraphs. If you run the optimized DirMap application (it doesn’t make much difference whether you compile it to native code or execute it from within the Visual Basic IDE) and time it, you’ll see that it’s consistently more than three times faster than the original application. Overall, it’s still a slow application when you,use it to map a folder like Windows or Program Files, but this application is useful in mapping smaller folders. , If you compile the DirMap application to native cod~ and execute it, you won’t seJe a considerable improvement in execution time. This is because p-code is quite efficient at manipulating strings: The rest of the code can’t be optimized. Most of the code manipulates the DirListBox and FileListBox controls and these operations can’t be made ‘any faster. When an ActiveX control takes over, there’s nothing you can do from ‘within the code to speed it up’. This is the “speed barrier” I talked about earlier in the chapter
There are certainly more applications in this book whose execution speeds aren’t optimal, and you can usethem to experiment with tl ie optimization techniques we have looked at in this chapter. For example, you cart use the technique of drawing on a device context to speed up the Spiral application of Chapter 6, Drawing with VISUal Basic. This can be an interesting exercise, as you’ll have to be creative with the AutoRedraw property to increase the subjective speed of the applicatien.
