Is it safe to ignore the potential inaccuracy of WM_GETTEXTLENGTH for Edit Controls?

Question

This doc page says

When the WM_GETTEXTLENGTH message is sent, the DefWindowProc function returns the length, in characters, of the text. Under certain conditions, the DefWindowProc function returns a value that is larger than the actual length of the text. This occurs with certain mixtures of ANSI and Unicode, and is due to the system allowing for the possible existence of double-byte character set (DBCS) characters within the text.

I assume none of these conditions can occur in a WCHAR edit control, since it's WCHAR only.

I feel like just ignoring them and using WM_GETTEXTLENGTH directly as my length. If it happens that WM_GETTEXTLENGTH doesn't just do a strlen operation to get its value, and instead has it precomputed, that would be good for performance. I guess I will have to look at the decompilation of notepad in ghidra to find out.

Answer 1

Well, I still don't know if it's that safe to rely on the length returned by WM_GETTEXTLENGTH, but it definitely is way faster than doing wcslen on the pointer you get from WM_GETHANDLE+LocalLock.

From a benchmark of a 4107893 char file. 
Time is total seconds taken to compute the length 512 times:

WM_GETTEXTLENGTH:
    Length: 4107893
    Time: 0.000058
wcslen:
    Length: 4107893
    Time: 0.623284

However, the performance of WM_GETTEXT/wcslen is probably not a problem. I realized that the slowness my app experiences is actually the same that notepad experiences, and it occurs when I call WM_REPLACESEL on a large document. For some reason, replacing any amount of text in a large document with that message is pretty slow.