What You Don’t Know Hurts You

Whether you use native code or p-code, you probably want your code to be as fast as possible. You wouldn’t have picked this book otherwise. Of course, it doesn’t make sense to optimize every statement. If you have a trade-off between speed and size, or between speed and reliability, or between speed and some other factor, you might not always choose speed. But you always want to understand the trade-offs, and you don’t want to write code that is unnecessarily slow when there is no trade-off.

But what’s faster? You can guess how Basic works and try to think through which techniques might be faster, but how can you know for sure? There’s only one answer. You have to time it. But timing code in a multitasking operating system is difficult and inconsistent. Let’s summarize what you don’t know about Visual Basic timing:

• Code in Windows DLLs is written in C or assembler and is thus native code, but you don’t know exactly when you’re running Windows code and when you’re running Basic code. Performance loss from p-code isn’t going to make much difference in code where Windows does most of the work.
  
  
• Code for Basic statements and functions is also native code—in the
  Basic run-time library. Disk access in particular is so much slower than native code or p-code that the difference between the two won’t be significant.
  
  
• A good algorithm in p-code usually beats a bad algorithm in native code.
  So get your algorithms right before you worry about anything else.
  
  
• In virtual memory operating systems such as Windows, smaller code often means less disk swapping. Any speed increase you get from
  native code is going to be washed out instantly if you have to hit the disk to swap your fast code into memory.
  
  
• Windows NT and Windows 95 are preemptive operating systems, which means that other programs can interrupt your code at any time. If you test a piece of code several times, you will get different results each time.
  
  
• Anything you do to time your code will itself take time, thus changing your results. You need to time the code while timing it and then time it while not timing it, and compare the results to see how timing it affects the timing. But you can’t.

A lot of variables come into play, but one thing is clear: to find the most efficient way of performing an operation, you need to test it multiple times.