I'm not sure I'd conclusively say zsh is faster. Yes, it takes less user time to execute your scripts. But the CPU load (sys) time is an order of magnitude less. It's probably preempting the CPU more, resulting in a longer user time, but lower system load. In anycase, yes, if the speed of the shell script in total time matters, zsh is good. But say you're on a VM or embedded system with 128MB of ram and a weak CPU... I'd rather run a long running watch on bash knowing it wouldn't furthur slow the process.
However, the customization/color options for zsh combined with the feature set are definately superior. This article has definately convinced my to atleast give zsh a shot.
The only downside for me is that I have hundreds of bash scripts around my codebase that were written to take advantage of bashisms and they would encounter errors. (Unless ofcourse I went in and explicitly added #! /bin/bash to each of these)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not sure I'd conclusively say zsh is faster. Yes, it takes less user time to execute your scripts. But the CPU load (sys) time is an order of magnitude less. It's probably preempting the CPU more, resulting in a longer user time, but lower system load. In anycase, yes, if the speed of the shell script in total time matters, zsh is good. But say you're on a VM or embedded system with 128MB of ram and a weak CPU... I'd rather run a long running
watchon bash knowing it wouldn't furthur slow the process.However, the customization/color options for zsh combined with the feature set are definately superior. This article has definately convinced my to atleast give zsh a shot.
The only downside for me is that I have hundreds of bash scripts around my codebase that were written to take advantage of bashisms and they would encounter errors. (Unless ofcourse I went in and explicitly added
#! /bin/bashto each of these)