but what does this tell us? I think kind of no news here.
It just means that I/O should be avoided and could always be a bottleneck (even if you use /dev/null and the /dev/null is highly optimized by the operating systems... the binary still needs to form the output and call the syscalls for the input/output). If you do not need to print each and every password candidate (but just hold it in memory for a few nanoseconds and manipuate/use it), you save a lot of other resources (no need to format the output, no I/O syscalls and no disk IO if not using /dev/null etc).
I'm not saying that there is absolutely no way to optimize --stdout a little bit, but it probably won't be more than a very small constant factor, in the best case. Feel free to make a pull request on https://github.com/hashcat/hashcat if you find some code improvements.
btw: I think the argument "-o /dev/null" could even be a little bit faster compared to the redirect with > /dev/null (but I didn't test it)
It just means that I/O should be avoided and could always be a bottleneck (even if you use /dev/null and the /dev/null is highly optimized by the operating systems... the binary still needs to form the output and call the syscalls for the input/output). If you do not need to print each and every password candidate (but just hold it in memory for a few nanoseconds and manipuate/use it), you save a lot of other resources (no need to format the output, no I/O syscalls and no disk IO if not using /dev/null etc).
I'm not saying that there is absolutely no way to optimize --stdout a little bit, but it probably won't be more than a very small constant factor, in the best case. Feel free to make a pull request on https://github.com/hashcat/hashcat if you find some code improvements.
btw: I think the argument "-o /dev/null" could even be a little bit faster compared to the redirect with > /dev/null (but I didn't test it)