4 ms·

I can't help but think that since he's measuring his own perception at the ms level - for a new program he's written himself - that it would be easy for unconsc

I can't help but think that since he's measuring his own perception at the ms level - for a new program he's written himself - that it would be easy for unconscious bias to creep in. To really know the truth about whether latency matters in this case, a better experiment is probably needed. Not that I think he should bother doing this, I'm just being the fun police. :)

majewsky 9y ago
I don't really know how to eliminate my own biases here, but a quick test shows that the new prompt feels very much like the old one if I add a little latency manually: PROMPT="\$(prettyprompt \$?)" PROMPT="\$(sleep 0.04; prettyprompt \$?)" With the second one, I can always see a frame or two where the cursor is already on the next line where the prompt will go, before the prompt actually shows up.
- darawk 9y ago
  Presumably the test would be whether he can, in a blind experiment, reliably discriminate between them.
  - alecbenzer 9y ago
    Yeah -- seems like it'd be a bit tricky to set up, but would be super interesting to see the results. edit: Tried something out: https://github.com/AlecBenzer/terminal-latency https://github.com/AlecBenzer/terminal-latency Had 92% accuracy differentiating 10ms from 100ms out of 28 tries
    - richdougherty 9y ago
      Nice!
tomxor 9y ago
No, you can easily measure this stuff with "time". It was 75ms vs 3ms for python vs go... this is for some custom prompt he wrote, so this is the time it takes to get the new prompt every time he was pressing return. I don't think it's that big a deal, if it was navigation keys in a text editor then it's a big deal, but when you hit return you are usually executing something much longer than ~50ms anyway so it's not an overhead that's going to multiply that much.
- tomxor 9y ago
  I just realised that may have come off as sarcastic... I was referring to "time" as in the linux cli tool, not the concept :P

majewsky 9y ago

I don't really know how to eliminate my own biases here, but a quick test shows that the new prompt feels very much like the old one if I add a little latency manually: PROMPT="\$(prettyprompt \$?)" PROMPT="\$(sleep 0.04; prettyprompt \$?)" With the second one, I can always see a frame or two where the cursor is already on the next line where the prompt will go, before the prompt actually shows up.

darawk 9y ago
Presumably the test would be whether he can, in a blind experiment, reliably discriminate between them.
- alecbenzer 9y ago
  Yeah -- seems like it'd be a bit tricky to set up, but would be super interesting to see the results. edit: Tried something out: https://github.com/AlecBenzer/terminal-latency https://github.com/AlecBenzer/terminal-latency Had 92% accuracy differentiating 10ms from 100ms out of 28 tries
  - richdougherty 9y ago
    Nice!

tomxor 9y ago

No, you can easily measure this stuff with "time". It was 75ms vs 3ms for python vs go... this is for some custom prompt he wrote, so this is the time it takes to get the new prompt every time he was pressing return. I don't think it's that big a deal, if it was navigation keys in a text editor then it's a big deal, but when you hit return you are usually executing something much longer than ~50ms anyway so it's not an overhead that's going to multiply that much.

tomxor 9y ago
I just realised that may have come off as sarcastic... I was referring to "time" as in the linux cli tool, not the concept :P