Exclusively Unicode, faster?

[ecube]

I read in another post windows has to convert things to Ansi since internally it's all unicode, this isn't news to me, is pretty much common knowledge I believe, but it did start to get me curious if working with Windows API as unicode exclusively instead of Ansi is noticeable faster, has anyone speed tested? And when I say noticeably faster I mean in the total life cycle of a process, assuming it was API intense and ran for awhile.

[daydreamer]

wouldnt it be time-able with measure difference on SendMessageA and SendMessageW etc to get how many cycles a conversion takes?

[Relvinian]

I read in another post windows has to convert things to Ansi since internally it's all unicode, this isn't news to me, is pretty much common knowledge I believe, but it did start to get me curious if working with Windows API as unicode exclusively instead of Ansi is noticeable faster, has anyone speed tested? And when I say noticeably faster I mean in the total life cycle of a process, assuming it was API intense and ran for awhile.

If you are using Win2000 (possibly NT4) and higher OS (non-win9x series), yes, it will be faster to use Unicode for API calls that have them. Otherwise, the Kernel will translate your ANSI characters to Unicode before passing them on the to the final API call.

Relvinian

[Mark Jones]

I had proven this to be false before (at least on my system using GoASM), and thought I made a post about it, but can't seem to find it now. In fact, I KNOW I made a post about this. Even google was tried and it can't find that post now, weird.

In any case, try it. Use Petroizki's or Michael's timing macros, and perform two sets of identical ASCII and Unicode text outputs. Their timings should be nearly identical (at least on XP SP2.)