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:
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 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:
name | rate |
---|---|
vimps1 | 1355 |
bash_ps1 | 141 |
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.
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.