No estoy seguro de cómo funciona el código de conexión de su teclado en segundo plano, pero primero, el Sr. Chen escribió en su blog sobre problema al usar PostMessage para este tipo de cosas. Como él dice, si desea enviar una entrada que se trabe en la cola del teclado, use SendInput .
Por ejemplo, una forma de capturar pulsaciones de teclas es usar SetWindowsHookEx y escriba un controlador de eventos como parte de una DLL cargada a través de LoadLibrary . Esto recibirá toda la entrada del teclado que alimenta el sistema y es una forma, por ejemplo, de implementar teclas de acceso rápido globales (como en, para todo el sistema).
El problema con este mecanismo es que si el enlace toma demasiado tiempo para procesar esa entrada, Windows lo arranca y nunca le pasa más mensajes. Encantador. Resulta que hay un error de Windows 7 en el que el sistema operativo chucks se engancha sin ninguna buena razón, también.
De todos modos, está bien, vuelve a la tarea. Es posible, como una explicación, que su keylogger no muestre ninguna diferencia de rendimiento mensurable porque no está realmente instalado. Esto vale la pena verificar.
En segundo lugar, sin embargo, si te enganchas, incurrirás en una penalización de rendimiento, sea lo que diga el discurso de marketing. Hay instrucciones adicionales que se ejecutan de cualquier forma que lo corte, ya que si está usando un controlador, Windows está haciendo ruido a través de un dispositivo adicional en pila de controladores y si está utilizando SetWindowsHook , Windows está enumerando y llamando a un gancho adicional.
Lo que podría estar yendo mal es el proceso de medición. Esto es bastante difícil de hacer, especialmente cuando se tienen en cuenta factores de confusión como los cambios de contexto, la demora de E / S, etc. Dependiendo de cómo intente medir el tiempo de entrada, es posible que simplemente esté perdiendo la diferencia.
Se vuelve más técnico que eso también, por ejemplo, rtdsc no funciona tan bien con múltiples -los sistemas centrales en estos días, así que si estás usando eso, podría no funcionar. Necesita la función API adecuada para obtener un temporizador de resolución decente.
Otro punto a tener en cuenta es la presencia de un depurador. Si alguna vez ha depurado una aplicación bajo, digamos, Visual Studio, será consciente de que los archivos DLL se cargan, los símbolos de depuración también se cargan, lo que introducirá demoras masivas. Estoy seguro de que te has dado cuenta de esto, pero vale la pena repetirlo.
Así es como me gustaría abordar esto:
- Escribir una aplicación de Windows. Registre
WM_KEYPRESS messages - time and keypress.
- Tener un hilo.
- Tiene un botón que activa el hilo para comenzar a enviar
SendInput messages.
- Ejecute este proceso por un tiempo: necesita obtener suficientes datos para negar cualquier factor de confusión.
- Detente.
- Repita con el keylogger cargado.
No hace falta decir que cargaría esto en una máquina física, no virtual, con la menor cantidad de ejecución posible.
¿Verás algo? Sinceramente, no lo sé. Parece que algunos lo han intentado utilizando esta y otras métricas, pero no tengo el privilegio suficiente de ser permitido para leer artículos que son el avance del conocimiento humano y que mis impuestos podrían haber contribuido. Si puedes, hazme saber si es bueno.
Detalles agregados puede producirse un cambio de contexto cada vez que realice una llamada a la API, pero no necesariamente se produce. Por ejemplo, si llama a una función relacionada con IO y la API debe bloquearse, su proceso se suspenderá y se ejecutará el algoritmo de programación para determinar si algún proceso en espera está muerto de tiempo o tiene mensajes de IO que necesitan manejar. Dependiendo de esto, usted, u otro proceso, podría ser despertado y ejecutado. El proceso se repite.
Si se merece un cambio entre procesos, esto es comparativamente costoso (en la escala de minutos que estaríamos midiendo aquí), luego se guarda el estado del registro actual, se describe su proceso y otro está mapeado. Esto es claramente más costoso que saltar de nuevo a la tierra del usuario.
Otros posibles gotcha son las interrupciones. En Linux (no estoy seguro acerca de Windows), las interrupciones se anticipan a todo cuando se permite su ejecución, por lo que una llamada puede tomar más tiempo simplemente porque durante ese tiempo, el kernel manejó más interrupciones que la vez anterior.
Las interrupciones no siempre (de hecho, probablemente no deberían necesitar) para cambiar el contexto del proceso, pero puede haber más o menos de ellas en cualquier momento, dependiendo de lo que esté haciendo el hardware. Más de ellos significa más ciclos de CPU entre la llamada y la finalización de esa llamada.