minor performance for getch

[GitMensch]

... just a suggestion (and warning: I did not even tried to compile that...)

• early loop back if there is no key ready - at least during debugging this was quite often the case [which is the main reason for this suggestion]
• only check for copy/paste if we don't have a mouse event [occurred to me during adjustment when reading the code]

I was not 100% sure if the copy/paste keys may apply to the "filter special keys if not in keypad mode", if they aren't then this also does not need to be done when we have a mouse event and then also not in the copy paste code.

[Bill-Gray]

Will give this a try. I have a bit of code to test key speed that fell out of issue #197. As noted therein, a recent change really boosted the response time (basically saying "if we didn't find a key a millisecond or less ago, just return 'no key found'; don't even check for a key hit until at least a millisecond has elapsed since our last check.") I think getting a speed improvement at this point will be very difficult. But I'm sometimes wrong.

[GitMensch]

Additional to the actual speed there should be always the consideration of cpu cycles / instructions spend.

I recommend to use 'perf stat -e instructions ./testprog' for doing that.

Thank you for giving this a try!

[GitMensch]

Any news here or, more important, for #245?

[Bill-Gray]

Can't say there was any performance improvement. (I'd have been surprised had there been one; the compilers probably optimize things to result in roughly what you did with the 'early return' scheme.) However... the code was slightly easier to follow your way, so I pulled it.