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 didnt come to my mind that I would have the following statistics to look at:

name rate type
Bash implementation
print_td 1856 Bash function calls
td.sh 159 Bash script executions
C implementation
td 52 C executions
Bash with C loadable extension
td 21631 Bash loadable executions
Python bindings
td.py 35 Python 2 script executions
td.py 12 Python 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 couldnt get it to work with latest vcprompt code at the time, which was linked into vimps1.

At the time, when I didnt really have the way to measure the performance, but I knew it ran faster. How would I know? Well, thats 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:

name rate
vimps1 1355
bash_ps1 141

Its 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 its not a bad shell, from time to time, I do hope it could run faster. It might be wrong to think so, since I havent really seen anyone really talk about shell performance.

After I finished td.shs C transition, I thought about making an extension that would do arithmetic with float number, but thats 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 dont understand how costly of an invocation, just look at the first table, 52 vs 21631 runs, thats the prize you have to pay. If you havent known, here is a tip for you, dont use external command in Bash script unless its something Bash cant 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 thats a because I can, then be my guest.