Which is more efficient:A Win32 func. or a similar CRT func. in a VC++ app.?

I started win32 programming for fun because I like complex things and I like programming(this is all Charles Petzold's and Jeffrey Richter's fault for writing such beautiful books.) and may be because I have a thing for performance code.

Now, the real question:I'll use the example of GetEnvironmentVariable()[a w开发者_StackOverflowin32 API func.] and getenv()[a standard CRT func.].

Both of these return the value of an environment variable provided as an argument.

So using which one would be more efficient or in other words which one has a shorter call stack of which one is more direct?Think of some func. being called a million times.

I believe that either of them maps to the other.Am I right or I'm missing something here.

Summary:While programming for win32 api, if there are functions available in both the api and the c/c++ libraries that offer same functionality, which one should I use?

thanks.

For most apps, it's unlikely that use of one or other API will be the primary performance concern.

The CRT and C++ Standard Library is mapped onto Win32 APIs so using Win32 direct will be slightly more efficient. If you need to write portable C code, use the CRT though.

In C++, most often, using the Standard Library allows easier production of idiomatically-correct code, and that outweighs any marginal performance gain from going direct to Win32.

getenv is perhaps not a great example because the mapping to Win32 is trivial. Consider instead reproducing <iostream> using the Win32 APIs, and the benefit of a good library becomes clearer.

Stick with the CRT. It maps to the WinAPI, but not necessarily directly. For example, printf() might map to WriteConsole, but with buffering for performance. If GetEnvironmentVariable() doesn't need any code wrapped around it, then getenv() will be the same performance, and if it does (such as buffering), then the CRT shall provide it. And it's "right", not "write".

Both functions are likely to be similar in performance, probably ending reading the values from the registry. But more importantly, there is no reason they should ever become a critical performance issue: registry is a database, if you need using some value from registry again and again, you cache it in some variable.