> In any case, when it comes to CPU usage, I believe there are far worse
> CPU hogs in a DC client. Stuff like searching and file hashing, and
> possibly even translation back and forth from UTF-8 are likely to take
> much more CPU than command parsing no matter how much you optimize them
> and no matter how many quoting styles you allow in the command
> parser. Since it is that way, I'd say that it's preferable to ease
> debugging as much as possible before simplifying the command parser
> for speed.

Well, yes, but the hub shouldn't need to bother doing this in any case,
thus no performance hit on the server side.

In fact, the choice is even easier. The hub cannot do it. To perform conversion from UTF8 to something else, the hub must know the charset used by each client and there is currently no command allowing a client to send this information to the hub.

About protocol charset, I think (binary or ascii protocol) UTF8 is better then UTF16 because, unlike UTF8, UTF16 conflicts with ASCII 7 bits and this means these characters (the one in conflict) must be escaped which will take more place than UTF8 (DC escape codes are infamous and too big).

Eric