blog: win32 string comparison performance

[nikos]

here's the comment area for today's blog post found at
https://www.zabkat.com/blog/case-conversion-timing.htm

[otlaolap]

Naturally xplorer² isn't doing string comparisons all the time, never mind half a million of them in a row, so here's another instance of striving for excellence, saving the last drop of CPU power, which turns out to be not really important, as we have seen time and again in this blog series...

and in my real life

[Tuxman]

Unsurprisingly, low-level API functions are more efficient than abstractions.

[johngalt]

I also find it interesting that the first method worsens on 64 bit architecture while the second method improves.

[nikos]

that is probably within the limit of clock accuracy, probably it's the same in both 32/64 bits

[Kilmatead]

...so here's another instance of striving for excellence, saving the last drop of CPU power, which turns out to be not really important, as we have seen time and again...

Spend enough time reading Stack Overflow (wondering how Raymond Chen's life might have gone differently with a dollop more "misspent youth" stirred in), and eventually you'll encounter (and empathise with) the endless references to Why Premature Optimization Is the Root of All Evil.

This is one of those things I've never been able to shake... if you learned programming back in (or before) <insert whatever year makes you feel old here>, you'll have grown up with the idea of 'optimisation' embedded in your thinking process. Never let it be said that I ever turned down an opportunity to remove a redundant iteration from a loop before even having finished typing the closing bracket.

It doesn't help that (even to this day), one of the slowest things you can do is print multiple formatted results to a console window. Not, of course, that you'd ever do that for time-critical use anyway, but it's always in the back of your mind, even if you haven't streamed output to a console in decades. In the C language, this always ended up giving the library function printf() and its seemingly endless siblings a bad name, undeservedly. It doesn't help that you know the more complex a function is, generally the slower it's going to peddle its bicycle up the hill - and of all functions the variadic printf-family/cult is a heck of a thing, options-wise. Again, this is a prejudice that I just can't shake (not because printf is slow - it isn't - I just feel that it is), but my earliest recollections of printing to scrolling screens (I was probably 10?), have inculcated in me a dread of everything printable. (Never mind the nightmare of darkened university labs where modems were slow and the DECwriter was the scariest thing to go clickity-clack in the night.)

Anyway, just to rub in a little absurdity into my already bedraggled thought processes, a project I was messing with required the repetitive concatenation of strings within buffers, which is always painful in the nul-terminated string paradigm so common of yesteryear low-level languages. The easiest method (in C, at least) is to just use something like swprintf() to format directly into a buffer and let it do all the hard work.

But here's where the programmers' arrogant prejudice raises its enticing little head and says, "Hey, I can write my own dedicated routine that's got to be thousands of times more efficient than using any printf-derivative." Sure, it'll take longer to write, but also be more fun to optimise and keep for another rainy-day project later. So, why not?

Feeling all very proud of myself and my well-ensconced afternoon, I wrote it up, and (of course) wanted to profile it in situ just to pat myself on the back, and say that my hand-rolled method kicked the same wprintf-variant to the kerb.

Anyone who's ever timed subsections of code knows a multitude of dirty (but effective) methods to use (rather than all the trouble of employing a "proper" profiler) - the simplest being GetTickCount() which will give you results in milliseconds, which is generally all you need. Of course, on a modern(ish) multi-core CPU overclocked to 4.7Ghz, my little code kept reporting "0ms" so I needed to bring a bigger microscope to bear, and the WinAPI's QueryPerformanceCounter() came to my rescue. This thing (for those who don't know) has up-to (or "down-to"?) nanosecond granularity (that's a billionth of a second, kids) which, while overkill, and of questionable accuracy on such a low-level, is a lot of fun to play with... to boys of a certain fetishistic mindset.

One should also note that to outmoded programmers of a certain ilk and age, conserving memory is also a consideration of efficiency, so the mantra of the day is "over-provisioning is a sin, and accurate dynamic allocation is the only dirty t-shirt that I'm going to wear." This sort of thing puts a further nail in the perceived coffin of sprintf(), because to get byte-accurate size buffers, you've got to first run your format-string through a function like _scwprintf() which doesn't actually do anything other than spend a lot of effort deconstructing your format-string and spitting out the number of wide-string characters you produce, to calculate the accurate buffersize you want. Only after which, of course, do you then get to call your final swprintf() to spit it all out.

Everything in the above paragraph just screams inefficiency... or at least leads you to hope that your compiler is intelligent enough to know when to cache and when to fold - which brings up the pitfalls of online poker, since I can't help but giggle with glee that there's a website named "Poker News Daily", and can't resist the urge to link to it every chance I get.

"But," you say to yourself, "where's the fun in that?" (meaning compiler efficiency, not online-poker). Relying on intelligent compiler optimising is (what we used to say on the playground) essentially a pansy-assed wussy approach to fighting the other kid.

Curiously, I discovered that even if you "officially" disabled all compiler optimisations just for the fun of it, the GCC-family (and, I think Clang/LLVM "suffers" a bit from this too), the compiler still generously activates at least 50 optimisations it doesn't deem worthy of mentioning, so these have to be disabled manually if you really want to roll up your sleeves. (And it also makes for a really long command-line compiler invocation string. You know it works though, when you end up with a binary that's 6 times the size of the old one.)

Anyway, the end-result is that _scwprintf()/swprintf() took 4μs (microseconds - or 4 millionths of a second) per iteration to execute and my hand-written code took (a rather consistent) 700ns (nanoseconds) to drop its bloomers per iteration.

So, yeah, mine was faster... but... what... how... who... life used to be so simple... feckin' microseconds? This is not a fair arena to do combat. What's the point? Humans can't even perceive microseconds. Well, maybe they can when their 747 smashes nose-first into the tundra, but they (usually) don't have much to say about the experience afterwards.

What does this tell us? Aside from avoiding air-travel, it tells us to remember again Nikos' prophetically hopeless, self-engineering-code condemning words:

...so here's another instance of striving for excellence, saving the last drop of CPU power, which turns out to be not really important...

Another wall of text day. So what did you do with your Sunday?

[pj]

...
Another wall of text day. So what did you do with your Sunday?

Worked on getting my wife's hurricane-destroyed car replaced. Such fun!

--------------------
PJ in (devastated) FL

[johngalt]

Hope all is well regarding the dmgs from the hurricane.

[pj]

JohnGalt,

We were extremely fortunate with no damage or power loss during Milton.

The hurricane eased south of the original forecast track. 20 miles further north and we'd have had major damage. We sat out the storm in Orlando with sister-in-law, wife's nephew and his family. Eyewall passed over about 3am, but the resort we are at had minimal damage and no loss of power. Many others were not so fortunate, especially with probably 40 confirmed tornados wrecking havoc along Florida's Atlantic coast from Ft. Lauderdale to Daytona and the second major storm surge within 2 weeks on the Gulf coast.

Keep us in your prayers during the weeks of recovery and restoration ahead.

----------------------
PJ in (devastated) FL

[johngalt]

Absolutely. I have a friend down in the Avon Park area, and he fared much better than he expected to.

I'm east of Atlanta myself. We got lucky in that the paths of Helene and Milton both went east of us, so we didn't face massive wind dmg as we could have (and as I was expecting to).

Thoughts, prayers, and parakeets for you and yours and the folks around you, as well as all those affected all over.