One of the key factors for them is that “their compiler makes small exes”… They never, ever, mention speed.

Some time ago I did a bunch of benchmarks, in a time where it was uncertain for me which language should I stick to (We all asked this question at least once) and I found some shocking results, but not surprisingly. You see, developing an efficient compiler is not an easy task. However, when someone talks their butt off a certain subject, be sure that they are hiding something else.

The benchmark ran a few simple, trivial tests such as single and multi-dimensional array access as well as a factorial test. All of which were linear. The languages I chose were C++, BlitzMax and PureBasic.

Results were loud and clear, PB was the slowest of all three tested languages with no exceptions.

For the linear array access, C++ did 700ms whereas BMX (BlitzMax) did 650ms, Sadly PB did 2160ms.

Similar pattern emerged in the multi-dimensional array test with C++ performing a whopping 1250ms against BMX’s 1750ms, again PB did a lousy job with 4330ms, ouch.

As for the factorial test: C++ 578ms, BMX 590ms, PB 1578ms.

Now, this are averaged results (out of 10 runs each). The versions used of each compiler were the latest, stable releases. And I just finished running the tests again, yielding the results I just showed you (which didn’t differ much from my old findings anyway).

For C++ I used the GCC frontend, I also compiled with the default switches. Reason being, I wanted to be “fair” with the other languages that don’t seem to provide any compiler switches at all regarding true code optimization. It’s also good to know that both PB and BMX use similar backends for assembly and BMX itself uses GCC for it’s C++ integration.

It is clear that PB’s compiler does a lousy job, period. Whenever you’re working on an application in the real world, a few extra KBs don’t matter as long as your program runs FAST. Obviously a more extense set of tests should be created to really call it final, but I don’t have high hopes for PB since it’s not a worldclass compiler, it can’t compete with C++, period.

“Programmers are the only men who boast how small theirs is.” – Wil Baden

Well Mr. Baden, I don’t. OK, Sometimes…

For those afraid of C++, did you ever try it or were you too scared of the syntax and decided it was too much for you?, do yourself a favor and look again, this time do make an effort and I promise you’ll soon get an epiphany the size of an elephant. If not, at least go for C#, Java, or Python! – Boy there are good choices out there.

You can find the benchmarks along with their source in here.

(notice this is quite an old piece of code, specially for the cpp tests; there are certain headers included that shouldn’t even be there in the first place. you could also get a smaller exe by avoiding iostream alltogether, ha)

That’s all I wanted to say, I’m really tired of how idiotic they can get with their product. It’s not like they’re offering something that doesn’t exist, they don’t even have a RAD or even the standard libraries and most importantly size doesn’t matter if you can’t perform at all… Oh well, I better wrap it up for now.

Cheers.

</rant></hate><love>

My first entry is the FindChar() routine. Unlike the official FindString(), this one only searches for a single character. In situations where you’ll be dealing with single character string searches rather than multi-character, this routine will give you up to 2x speed increase in both Ascii and Unicode modes. Worst case scenario, you’ll get equal results speed-wise.

The FindChar() code can be found at > here <

Due to the fact that Unicode characters are 2bytes long, we must use SizeOf() to perform certain displacement operations. However, this implies the use of at least one division for our final result, this will slow things down in the long-run. So, instead, we hack ourselves into a nastier method and we thank the FPU for it (granted, multiply by 0.5, since we know the character size is constant at 2) As nasty as it is, this allows us to outperform the official routine by almost 2x, still in Unicode.

There are certain things to take care of before doing anything with my routines, and this includes making sure we pass a valid string pointer, while ensuring we never pass negative displacement values and that we don’t attempt to displace over the limits of the string. Any self-respectable coder will do this before calling any routine, though. If you want an extra push of speed, get rid of the main IF statement in the routine.

The ideal solution for this language would be to trash the actual string library and replace it with a proper one, but I fear this is a task for the author, not us. I also fear, we won’t be seeing this any time soon. So we might as well keep on sharing our solutions and “hope” the author reads a few books on proper software development, and that he understands them.

For those of you using Unicode, please beware that this routine has not been extensively tested on a production level. Even though it behaves equally to FindString(), I recommend you to perform at least a few tests before plugging this routine right into your main-code. It’s worth noting though, most of my string routines work on 0-based displacements but output equally to the official PB ones.

One of this days I’ll probably end up ranting quite badly on the fact that this sort of languages lack standad support for some really important routines… On the bright side, they provide quick means of prototyping small pieces of code before getting into production with your main language. Even so, theres no escape on the fact that the author lacks the real-world development experience to provide better solutions for his own product.

That’s it for now, I’ll be sharing more as I find time to post in here. Most of the rutines are being used on my in-house XML parser, just so you know. All benchmarks were done on multiple processors and results were averaged on a set of 20 tries per test.

Cheers.