VBspeed / Rules
Rules
Submissions · How I Time · The Charts · Le Grand Prix de la Speed

Submissions

If you want to win you have to submit some piece of code, and here is what it should be like:
  1. Your code must work perfectly according to the specification of the function. However: where already existing native functions are emulated (cf. VB6 to VB5), it will be *my* specifications, not necessarily Microsoft's. For example: many native VB-functions allow for Null-values to enter and be returned. This is, as far as I see, mainly, if not only, useful for Database business. Handling Null, however, is very bad for speed because it can only be done with Variants, which are the lamest of the lame. So: I will go for strong typing and just forget about Nulls for the time being. (It's easy enough to make any given procedure Null-compliant post-hoc if needed.)
  2. Your code must be 100% solid against any input (in IDE and native-compiled). Crash-code is immediately forwarded to the recycle-bin.
  3. Of course, your code should be fast if not the fastest. So please, check out the speed before you submit it. And that is: the speed compiled to native code and with all advanced compiler optimizations enabled. It's not enough to run the stuff in the IDE because things can look quite different there. Especially numerical operations get a considerable boost by compiling.
  4. Source code is confined to Visual Basic, core-API and custom typelibs. No inline-assembly (since 22-Oct-2001), no calls to OCX, no third party or self-written DLLs.
  5. If you call API, please supply the declarations, too.
  6. If you are the author of a typelib, please supply the typelib source code (IDL), too. It will be shown here.
  7. For the sake of maintenance: keep the scope of your variables is tight as possible. Lifting your local stuff up to the declaration section is likely to speed things up, I know that. You don't have to prove it to me.
  8. Make everything as readable as possible, nicely indented and precisely-concisely commented, etc. ... a bit of elegance can't harm.
  9. Put your name and, optionally, email and date into the first line of your code, for example:
    10.   Public Function XYZ() as Boolean
  ' by Donald Lessau, donald@xbeat.net, 20011122
  10. You'll email that piece of code to me, and I will time it against the pieces already in the game. If you win, you will enter the charts of fame for that discipline at position ONE, and you'll never be forgotten! All others will humbly shift down to where they belong. If you don't win, you can still enter the charts at the position you earned yourself, but only if your code is an original new solution to the problem, or if it considerably improves some already submitted code.
  11. We are open source: the code you submit will be published on this site, along with your name, email and URL. You *can* stay anonymous if you prefer, but at least your code will be shown (if it's good enough to break into the charts, that is).
  12. I will rename your functions (suffix a serial number, eg. 'Split04'), so that all competitors can run in one project without name conflicts.

top


How I Time

I will time your code, and I will decide who's the winner. Here is how I do it:
  1. Generally, performance timing under Windows is not a trivial thing when you want the real truth in exact CPU cycles or nano-seconds, because there's a lot of background noise in a multi-tasking environment. However, for our purpose, relative speed measurement is all we need, and that can be done well enough.
  2. I use the QueryPerformanceCounter API, and it ticks 1,193,180 times per second on my Pentium II and 3,579,545 times per second on my Athlon XP. You can download the (VB5-)class I wrote for this if you're interested: download CTiming.cls (zipped, 2KB, update 15-sep-2004). Check out more details on the History of Profiling Windows and on how far we can trust those 1,193,180 (3,579,545) ticks...
  3. The test environment:
    - till July 2002: Pentium II 350, 64 RAM, Win95, IE5.0
    - after July 2002: Athlon XP 2000+, 256 RAM, Win XP Pro SP1, IE6.0
  4. All timing is done with VB5 and VB6, compiled to native code, optimized for speed, not (since 16-Nov-2001) favoring PentiumPro, and having all Advanced Optimizations enabled, in other words having all checks turned off.
    Note, that you have to test your applications carefully before you turn all checks off. I found, that especially "Remove Integer Overflow Checks" can lead to pretty nasty and hard to track errors.
  5. By the way, comparing VB5 and VB6, VB5 is most of the times a bit faster than VB6. But I wouldn't bet on this...
  6. I run the candidate code thru a loop of several 100,000 iterations (called as a Public procedure located in a BAS-module), and I do this several times. From the collected results I calculate an average value, so that the average multi-tasking noise is part of the final number.
  7. Note: still, the resulting numbers are highly specific to the setup of the operating system, and it's very probable that they would come out differently on your computer. For example, I observed, that after installing IE5, almost everything slowed down, some functions even by ca. 50%!
  8. There's a lot more to say about VB performance and timing, some of it pretty strange actually ... i'll come back to this when I get the time.

top


The Charts

  1. Column layout: First column is position, second column is time ratio, third column is time per call (usually in microseconds). The fastest is marked goldish, the second-best silverish.

  2. Time Ratio: The best code in each chart is set to 1.00, the slower ones to a higher number according to their performance. So, for example, a 21.38 means: this code is over 21 times slower than the best.
  3. Time/Call: Average time per call on my machine (Athlon XP 2000+, 256 RAM, Win XP Pro SP1, IE6.0; till July 2002: PII 350, 64 RAM, Win95, IE5.0). The unit is µs (microsecond = 1 millionth of a second) where the best call is faster than 1 millisecond, else it's ms (millisecond) so that the numbers don't get too long and hard to read.
  4. Doping: All stuff beyond straight VB that's needed to make this code run fast resp. run at all.
    API = API functions have to be declared outside the timed procedure.
    TLB = project must reference a custom type library.
    ASM = code uses pre-generated in-line assembly code.
  5. Call 1, 2, 3 ... For some disciplines we will need more than one test call because the relative performance of an algorithm can depend on the specific makeup of the input parameters. For example, while doing the same job on a string, code A can be better with short strings while code B is better with long strings.

top


Le Grand Prix de la Speed

If you're a champion, help yourself, choose your favorite color:

     

And, hey, if not, here's something for you, too:



Wanna link to VBspeed? Have a button:

top


VBspeed © 2000-10 by Donald Lessau