Non sono sicuro di come il codice di aggancio della tastiera funzioni in background, ma per prima cosa, Mr Chen ha scritto sul blog problema nell'uso di PostMessage per questo tipo di cose. Come dice, se vuoi inviare un input che rimane bloccato nella coda della tastiera, usa SendInput .
Ad esempio, un modo per acquisire i tasti è usare SetWindowsHookEx e scrivi un gestore di eventi come parte di una DLL caricata in LoadLibrary . In questo modo riceverai tutti gli input da tastiera che alimenterai il sistema, ed è un modo, ad esempio, per implementare i tasti di scelta rapida globali (come in, per l'intero sistema).
Il problema con questo meccanismo è che se l'hook richiede troppo lungo per elaborare quell'input, Windows lo avvia e non gli passa mai più messaggi. Charming. Si scopre che in realtà c'è un bug di Windows 7 in cui il sistema operativo ganci di aggancio per nessuna buona ragione , anche.
Comunque, OK, torna al compito. È possibile, come spiegazione, che il tuo Registratore di tasti non mostri alcuna differenza di prestazioni misurabile perché non è effettivamente installato. Vale la pena verificarlo.
In secondo luogo, comunque agganci, incorrerai in una penalizzazione delle prestazioni, qualunque sia il discorso del marketing. Vengono eseguite ulteriori istruzioni indipendentemente dal modo in cui la si ritaglia, poiché se si utilizza un driver, Windows sta facendo clangori attraverso un dispositivo aggiuntivo in stack di driver e se stai utilizzando SetWindowsHook , Windows sta eseguendo l'enumerazione e chiamando un hook aggiuntivo.
Ciò che potrebbe andare storto è il processo di misurazione. Questo è piuttosto difficile da fare, specialmente quando si considerano fattori di confondimento come interruttori di contesto, ritardo IO, ecc. A seconda di come si tenta di misurare il tempo di immissione, è possibile che manchi la differenza.
Diventa anche più tecnico, ad esempio, rtdsc non funziona molto bene con il multi -core sistemi in questi giorni, quindi se lo stai usando, potrebbe non funzionare. È necessaria la funzione API appropriata per ottenere un timer di risoluzione decente.
Un altro punto da notare è la presenza di un debugger. Se hai mai eseguito il debug di un'applicazione sotto dire Visual Studio, sarai ben consapevole del caricamento delle DLL, del sovraccarico dei simboli e dei ritardi. Sono certo che te ne sei reso conto, ma vale la pena ripeterlo.
Ecco come mi avvicinerei a questo:
- Scrivi un'applicazione Windows. Registra
WM_KEYPRESS messaggi - tempo e pressione del tasto
- Hai una discussione.
- Avere un pulsante che attiva il thread per iniziare a inviare
SendInput messaggi.
- Esegui questo processo per un po 'di tempo - devi ottenere abbastanza dati per annullare qualsiasi fattore di confusione.
- Stop.
- Ripeti con il keylogger caricato in.
Inutile dire che lo caricherò su una macchina fisica, non virtuale, con il minor numero possibile di corse.
Vedrai qualcosa? Onestamente, non lo so. Sembra che alcuni abbiano provato a utilizzare questa e altre metriche, ma non ho privilegi sufficienti per essere autorizzato leggere documenti che sono il progresso della conoscenza umana e che le mie tasse potrebbero aver contribuito a Se puoi, fammi sapere se va bene!
Dettagli aggiunti può verificarsi un cambio di contesto ogni volta che effettui una chiamata API, ma non necessariamente. Ad esempio, se si richiama una funzione relativa all'IO e l'API deve bloccare, il processo verrà quindi sospeso e l'algoritmo di pianificazione verrà eseguito per determinare se eventuali processi in attesa sono affamati di tempo o hanno messaggi IO che devono essere gestiti. A seconda di questo, tu o un altro processo, potresti essere svegliato ed eseguito. Il processo quindi si ripete.
Se è meritato un passaggio tra i processi, questo è relativamente costoso (sulla scala dei minuti che dovremmo misurare qui), lo stato del registro corrente viene salvato, il processo viene mappato e un altro è mappato in. Questo è chiaramente più costoso che tornare a terra dell'utente.
Un altro potenziale trucco sono gli interrupt. Su Linux (non sono sicuro di Windows), le interruzioni prelevano tutto quando è permesso l'esecuzione, quindi una chiamata potrebbe impiegare più tempo semplicemente perché durante quel periodo il kernel ha gestito più interrupt rispetto alla volta precedente.
Gli interrupt non sempre (in realtà, probabilmente non dovrebbero essere necessari) per cambiare il contesto del processo, ma potrebbero essercene più o meno in un dato punto, a seconda di cosa sta facendo l'hardware. Più di loro significa più cicli della CPU tra la chiamata e il completamento di quella chiamata.