¿Por qué la representación de secuencias de caracteres multibyte es increíblemente lenta?

Hace aproximadamente una semana me di cuenta de que la lista de archivos en µTorrent se colgaría por menos de un segundo cada vez que un archivo con un nombre de archivo japonés largo fuera visible. Me pareció curioso, pero en realidad no tuve tiempo de preocuparme por eso en ese momento, especialmente porque solo estaba limitado a µTorrent.

Sin embargo, hoy me di cuenta de que no lo es. Si, por ejemplo, guardo un archivo de texto con un nombre de archivo de caracteres multibyte largo y lo abro en el Bloc de notas, obtengo algunos resultados extraños. Cuando intento cambiar el tamaño de la ventana, todo se ralentiza. Sin embargo, puedo soltar mi agarre en la ventana y ver cómo mi cursor se divide en dos , uno controlado por mí y el otro como una especie de "cursor fantasma" por falta de una palabra mejor que ejecute el movimiento de arrastre que hice originalmente con el ratón. Esto solo se aplica a nombres de archivo de esta naturaleza, y también lo he probado en otras aplicaciones que no sean Notepad y µTorrent.

Intenté buscar pistas sobre qué está causando este extraño comportamiento, pero no puedo encontrar nada. ¿Alguien aquí tiene alguna idea de lo que está pasando?

Desafortunadamente, no puedo tomar una captura de pantalla de esto, ya que parece que todas las aplicaciones de captura de pantalla se cuelgan hasta que se completa el cambio de tamaño antes de tomar la foto ...

Editar: grabé un video que demuestra el problema. No estoy seguro de si esto ayudará a identificar la causa, pero al menos debería ser mejor que mi explicación anterior:

https://vimeo.com/58619918

Edición 2: Aquí hay un archivo de muestra según lo solicitado: Tenga en cuenta que es simplemente un archivo vacío con un nombre de archivo largo multibyte: http://goo.gl/bgnGP (Y para aquellos de ustedes con un navegador que no puede manejar el nombre de archivo, aquí está un archivo zip: https://dl.dropbox.com/u/55495248/multibyte.zip )

Puedo explicar cómo se maneja Unicode, pero no puedo responder directamente a su pregunta. He tenido lentitud para la primera escritura, pero una vez hecho esto, se vuelve a acelerar ...

Unicode se compone de lo que llamamos planos. Los planos son de 256 caracteres. En muchas situaciones, las fuentes manejarán un plano, en parte para evitar archivos muy grandes, pero también porque es suficiente para muchos idiomas (inglés, francés, alemán ...). Sin embargo, los idiomas asiáticos hacen uso de fuentes más grandes que cubren múltiples planos. Para un conjunto completo de caracteres japoneses, obtendría, si estoy en lo cierto, unos 10 planos. El chino es más (¡especialmente el chino tradicional!)

Al renderizar con tales fuentes, debe seleccionar la fuente correspondiente (si una fuente no es suficiente para manejar todos los caracteres, el sistema operativo cambia entre las fuentes por usted; eso está bajo el capó, pero sucede). Eso lleva mucho tiempo. Además, la primera vez que el sistema escribe en esa fuente, debe cargarla desde el disco. Idiomas asiáticos que tienen fuentes grandes, eso también lleva tiempo.

Finalmente, y eso es probablemente más probable con lo que te encuentras, los caracteres (o glifos) son generalmente más complejos. Eso significa más tiempo para representar los personajes. Aunque eso podría hacerse mediante la placa de video con OpenGL / D3D, para las fuentes, eso no es tan bueno. Pierde mucha calidad (aunque la calidad de fuente en MS-Windows ...) Por lo tanto, el procesador lo hace con mayor frecuencia.

Una última nota, aunque realmente dudaría de que sea una preocupación, por defecto Win7 hace que los bordes de la ventana sean semitransparentes. Podría ser que se suma al problema. Sin embargo, esta parte del renderizado se realiza con las funciones aceleradas 2D / 3D en su placa de video.

Si su PC representa un carácter multibyte, se vuelve más lento porque quizás tenga que hacer más de 1 instrucción para procesar el carácter.

Una versión de 64 bits podría obtener el nombre de 64 bits en 1 llamada, procesarlo en 1 llamada y almacenarlo en 1 llamada = 3 llamadas.

Una versión de 32 bits tendrá que funcionar con los primeros 32 bits, luego los otros 32, y luego administrar ambas operaciones:

obtener el nombre de 64 bits en 3 llamadas, procesarlo en 3 llamadas y almacenarlo en 3 llamadas = 9 llamadas.