True, I agree it's not necessarily a good way to test the filesystem, but it's only the shell that's being hit, nothing really to do with the terminal.
I pointed it out mainly because terminals can have a significant impact on performance, because dumping millions of lines a second isn't their intended purpose,[1] whilst the shell can be reasonably expected to do that.
Having it entirely as a shell built-in possibly actually better than the equivalent '/bin/ls > somefile' since it doesn't need to context switch back and forth as the stdout buffer fills up and the shell has to write it.
[1] I recall there being a Gentoo-related thread about why "Gentoo-TV" -- having the output of gcc scroll past as your background with a transparent xterm -- was actually slowing down package builds significantly.
I pointed it out mainly because terminals can have a significant impact on performance, because dumping millions of lines a second isn't their intended purpose,[1] whilst the shell can be reasonably expected to do that.
Having it entirely as a shell built-in possibly actually better than the equivalent '/bin/ls > somefile' since it doesn't need to context switch back and forth as the stdout buffer fills up and the shell has to write it.
[1] I recall there being a Gentoo-related thread about why "Gentoo-TV" -- having the output of gcc scroll past as your background with a transparent xterm -- was actually slowing down package builds significantly.