This June, I started to working on transitioning td.sh into a C project as well as using GNU Autotools to build. When I decided to do it, it didn’t come to my mind that I would have the following statistics to look at:

nameratetype
Bash implementation
print_td1856Bash function calls
td.sh159Bash script executions
C implementation
td52C executions
Bash with C loadable extension
td21631Bash loadable executions
Python bindings
td.py35Python 2 script executions
td.py12Python 3 script executions

As you could see, the C loadable extension for Bash undoubtedly beats everyone else, 10+ times better in performance. Because of this, I decided to bring back vimps1, which was quietly disabled last August, when I couldn’t get it to work with latest vcprompt code at the time, which was linked into vimps1.

At the time, when I didn’t really have the way to measure the performance, but I knew it ran faster. How would I know? Well, that’s simple, just holding down Enter and see the rate of prompt showing up. You could feel it when you used loadable extension or just pure Bash PS1.

Because of td.sh, now I have just brought back vimps1, although it has a problem with Git repositories, you could still see the benefits:

namerate
vimps11355
bash_ps1141

It’s more than 10 times because bash_ps1 is a seriously stripped down version of my normal Bash PS1.

Not many people are aware how bad their shell or prompt is wasting, probably nobody else cares. However, I begin to think, maybe I need a shell that having performance in its feature list. Bash, although it’s not a bad shell, from time to time, I do hope it could run faster. It might be wrong to think so, since I haven’t really seen anyone really talk about shell performance.

After I finished td.sh’s C transition, I thought about making an extension that would do arithmetic with float number, but that’s just wrong to do so, because if you want to make Bash does float, you need to patch Bash or just use other programming language to write the whole code, I have seen a lot of people using bc. Frankly, they truly are doing it all wrong.

Note

In September, 2014, I did make a project, e.bash, by forking e, tiny expression evaluator. It is a Bash builtin, and “because I can,” so I did it.

They don’t understand how costly of an invocation, just look at the first table, 52 vs 21631 runs, that’s the prize you have to pay. If you haven’t known, here is a tip for you, don’t use external command in Bash script unless it’s something Bash can’t do.

Note

In Feburary, 2015, I realized there is a very simple example using true to see the performances and costs.

And if most of code is relying on external commands, maybe you should consider writing in a language could do all the tasks. Nevertheless, if that’s a “because I can,” then be my guest.