Actually, from d3dx9shader.h:

typedef LPCSTR D3DXHANDLE;

A D3DXHANDLE is just a string.

I believe that the MSDN page you've linked is slightly misleading; what should be the slower part is all of the Get* calls, as they would require parsing the effect and searching for the name. Doing them upfront at creation time rather than at runtime should mean that once you have the handle - I'm assuming (i.e. I haven't seen the source code for D3D9 Effects so I don't actually know...) that Effects is using a hash table or similar container to map each handle to it's register slot - it's actual underlying register can be retrieved more quickly and without all of the parsing/searching.

Yea, D3DXHANDLE is a typedef of a const char*, but that doesn't mean it is a string. Just try it and read it as a null-terminated string, you won't get anything usefull.

It's done this way to allow you to use a string literal instead of the handle value found by some Get* call. Because the functions (for example Effect::SetVector) expect LPCSTR as the first parameter, you can directly write

SetVector("someName", &value)

or if you already have the handle, you can pass it instead of the string and it will also compile and work.

It's faster to get all needed handles once (at the start) and then just use them so the string comparisons and searching isn't done again and again. I repeat - the D3DXHANDLE value ISN'T actually a string, so using it does no string comparisons. As Squared'D said - Direct3D has a simple way how to distinguish the two cases (probably by some special bits), so it knows how to behave.