2 ms·
Did you run those two commands in sequence? Did you account for disk-cache effects? Try running it 4 times, alternating the versions and see what your last 2
by jasonjayr 11y ago
Did you run those two commands in sequence? Did you account for disk-cache effects? Try running it 4 times, alternating the versions and see what your last 2 times are ...
- clebio 11y agoAll valid points, but (anecdotally) over the past several years of work, this holds true.
- vacri 11y agoYou can actually show different speeds in different terminals - the speed of terminal rendering affects the duration of the test. In the tests below, I have no custom terminal prompts or similar (no git status lines etc) - they're all distribution defaults running bash. # all the below run in the same MATE desktop # lxterm (from lxde - is easiest on my eye) $ time ls -R /usr real 0m19.974s user 0m0.860s sys 0m0.832s # gnome terminal $ time ls -R /usr real 0m19.902s user 0m0.800s sys 0m0.776s # xterm (yes, it really is 10x the speed) $ time ls -R /usr real 0m1.872s user 0m0.856s sys 0m0.800s # rerun in the first terminal, and the time hasn't changed - still 19s # now in lxterm redirecting to null # (and xterm gives similar results here) $ time ls -R /usr > /dev/null real 0m0.418s user 0m0.256s sys 0m0.156s All that prettification and rendering takes time; if you want raw speed, use xterm... or pipe output to /dev/null. Interestingly, 'time' on gterm and lxterm had tabs between the above field:value pairs (I had to reformat to show them nicely), but xterm used spaces. I don't know enough about the terminal underpinnings to guess as to why.