Should it be this slow?

[vefatica]

I've been using some pretty long command lines lately and I've noticed a behavior that's annoying and surprising.

I type a 300-character command line ... <Home> to the beginning ... press and hold <Delete> ... characters are deleted at a rate less than 2 per second!

And, if, after 15 characters have been deleted, I release the <Delete> key, there are enough <Delete>s in the input queue to delete the remaining 285 characters.

If that slowness is outrageous, what might be wrong here? And can anything be done about the build-up of characters in the input queue?

 

[rconn]

Not reproducible here (either the slowness or extra characters getting stacked up in the queue).

You've reported this before - is this something newly (re)occurring in v21? Did you try it w/o TCMD.INI?

 

[vefatica]

Not reproducible here (either the slowness or extra characters getting stacked up in the queue).

You've reported this before - is this something newly (re)occurring in v21? Did you try it w/o TCMD.INI?

It's considerably faster without TCMD.INI and the build-up of ketstrokes doesn't happen. What would be in TCMD.INI that would affect that?

 

[vefatica]

I had several "NormalKey"s in there. Removing them didn't help.

 

[vefatica]

And removing "InputColors" didn't help.

 

[vefatica]

And I just tried a few more times with /ii... this time, no improvement.

 

[rconn]

Assuming you don't have (all) logging enabled, and you're not using ANSI or input colors, then the limiting factor is the speed of the Windows WriteConsole API on your system.

 

[Charles Dye]

It's reasonable here, on my rather slow work computer. Do you have any keystroke plugins loaded?

 

[vefatica]

My original report was with 8 other TCCs running (2 in their own consoles, sitting in BTMs after having started WINDUMP, and 6 in pipes, generally doing nothing). I don't know why those might affect it, but it gets a little better without them.

With only one TCC, no INI file, no TCSTART, and no plugins, I get this:

ECHO %@REPEAT[x,339] > clip: ... paste clip: on the command line (about 3 112-character lines) ... <Home> ... press and hold <Delete> ... it takes about 11 seconds for one line (112 characters) to be deleted ... at that moment I release <Delete> ... all the remaining characters are deleted.

The sizes of the console screen buffer, font, and window don't matter. My KB repeat rate is 30 cps, the max.

 

[vefatica]

One odd thing ... even without the INI file (/ii) I still get ANSI colors ... ??? (And I use input colors.)

 

[rconn]

One odd thing ... even without the INI file (/ii) I still get ANSI colors ... ??? (And I use input colors.)

That seems unlikely, unless you've got an alias overriding your command line.

 

[vefatica]

OK, ANSI was coming from AutoRun which defaults to "Yes" (IMHO, it shouldn't) with no INI file. So I got rid of ANSI and repeated my last test (no INI, no TCSTART, no plugins) with the same results.

 

[vefatica]

Not reproducible here (either the slowness or extra characters getting stacked up in the queue).

You've reported this before - is this something newly (re)occurring in v21? Did you try it w/o TCMD.INI?

It really seems like DEL keystrokes accumulate and are processed long after the key is released (even without an INI file). I can defeat that with a keyhandler plugin. With this in place, deleting stops as soon as the key is released.

    switch ( lpki->nKey )
   {
       case DEL : // DEL = (83+FBIT) = 65619
           if (!(GetAsyncKeyState(VK_DELETE) & (1<<16)))
           {
               lpki->nKey = 0;
               break; // and return 0
           }

 

[vefatica]

Never mind. I found that if I push it enough, nearly all keystrokes accumulate.

 

[AnrDaemon]

Do keep in mind that using clipboard can be slow for unrelated reasons. Various "helpful" programs trying to monitor for clipboard changes incur the penalty, sometimes severe.