blocks|key|2220472|text|基于这份文件，内置程序比外部命令执行得更快，而外部命令通常需要分离单独的进程，因此，如果您非常关心性能，那么应该在可能的时候使用内置程序来执行，尽管我们讨论的是改进进程的时间顺序。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2220473|这通常只在紧密循环中多次运行同一命令时才会起作用，而不是使用单个命令处理整个输入。|2220474|另一个注意事项是，如果您意外地对您的机器进行了分叉轰炸，您将不再能够运行新的进程，但是您将能够运行内置的kill来尝试恢复。|style|CODE|2220475|entityMap|0|LINK|mutability|MUTABLE|url|http://www.tldp.org/LDP/abs/html/internal.html^0|2|4|0|0|0|1G|4|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@$A|X|B|Y|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Based on <a href="http://www.tldp.org/LDP/abs/html/internal.html" rel="nofollow">this documentation</a>, builtins execute faster than external commands, which usually require forking off a separate process, so if you cared deeply about performance you should do things with built-ins when you can, although we're talking about an improvement on the order of the time to fork a process. 

This will usually only matters when you're running the same command multiple times in a tight loop, rather than processing an entire input with a single command.

One additional note is that if you have accidentally fork-bombed your machine, you will no longer be able to run new processes but you will be able to run built-in's like <code>kill</code> to try to recover.

blocks|key|717949|text|调用外部工具会导致很大的性能损失。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|717950|让我们自己测试一下，将cut的10,000个迭代与参数展开的10,000个迭代进行比较：|offset|length|style|CODE|717951|#+for+me,+this+is+~50s+wall-clock
time+for+((i=0;+i<10000;+i%2B%2B));+do
++in_str='hello:world'
++cut+-d:+-f2+<<<"$in_str"+#+External+tool!
done+>/dev/null|code-block|syntax|javascript|717952|...vs...|717953|#+for+me,+this+is+~0.2s+wall-clock
time+for+((i=0;+i<10000;+i%2B%2B));+do
++in_str='hello:world'
++printf+'%25s\n'+"${in_str#*:}"+#+Builtin!
done+>/dev/null|717954|复制和粘贴这两种方法，看看你的结果有何不同.:)|717955|在我的系统上，内置版本在不到1秒的时间内运行，而外部版本则需要大约50秒才能运行。因此，我们正好在8个基点-2个数量级左右。|717956|现在，对于概念上的理解--需要理解的关键之一是，内置的所有工作都是在bash内部执行的，而外部工具需要大量的开销来调用：|717957|fork()从bash进程的第二次副本中删除|unordered-list-item|717958|execve()，将新进程替换为所需外部可执行文件的副本(通常要求操作系统调用其链接器和加载程序以旋转动态二进制文件)。|717959|用于完成该过程的wait()|717960|...and，如果您要捕获输出，那么还需要创建一个FIFO并从中读取。因此，启动外部工具的过程通常比该工具执行其所需功能的时间慢得多。|717961|也就是说--如果您注意到了，您可能已经注意到，这为cut构造了一个最坏的场景，每次调用只处理一行输入。在这方面，结果将大不相同：|717962|#+for+me,+this+is+~0.12s+wall-clock
time+for+((i=0;+i<10000;+i%2B%2B));+do
++printf+'%25s\n'+'hello:world'
done+%7C+cut+-d:+-f2+>/dev/null|717963|...wherein只对整个流使用一次cut调用，将启动时间扩展到非常多的输入行。|717964|当作业涉及处理大量输入，而不是一次一行时，正确使用外部工具可以提高效率。|717965|entityMap^0|0|B|3|0|0|0|0|0|0|0|0|6|0|0|8|0|8|6|0|0|P|3|0|0|J|3|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@$D|1H|E|1I|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|1J|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1K|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|1L|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|1M|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1N|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1O|8|@]|9|@]|A|$]]|$1|W|3|X|5|Y|7|1P|8|@$D|1Q|E|1R|F|G]]|9|@]|A|$]]|$1|Z|3|10|5|Y|7|1S|8|@$D|1T|E|1U|F|G]]|9|@]|A|$]]|$1|11|3|12|5|Y|7|1V|8|@$D|1W|E|1X|F|G]]|9|@]|A|$]]|$1|13|3|14|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1Z|8|@$D|20|E|21|F|G]]|9|@]|A|$]]|$1|17|3|18|5|J|7|22|8|@]|9|@]|A|$K|L]]|$1|19|3|1A|5|6|7|23|8|@$D|24|E|25|F|G]]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|26|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|1E|$]]

Calling external tools incurs a substantial performance penalty.

Let's test this ourselves, comparing 10,000 iterations of <code>cut</code> against 10,000 iterations of a parameter expansion:

<pre><code># for me, this is ~50s wall-clock
time for ((i=0; i&lt;10000; i++)); do
 in_str='hello:world'
 cut -d: -f2 &lt;&lt;&lt;"$in_str" # External tool!
done &gt;/dev/null
</code></pre>

...vs...

<pre><code># for me, this is ~0.2s wall-clock
time for ((i=0; i&lt;10000; i++)); do
 in_str='hello:world'
 printf '%s\n' "${in_str#*:}" # Builtin!
done &gt;/dev/null
</code></pre>

Copy-and-paste both of these, and see how your results differ. :)

On my system, the built-in version runs in less than a second, whereas the external version takes about 50 seconds to run. Thus, we're right around 8 base-2 orders of magnitude.

<hr>

Now, for a conceptual understanding -- one of the key things to understand is that all work involved in the builtin is performed internal to bash, whereas the external tool requires substantial overhead to invoke:

<ul>
<li><code>fork()</code> off a second copy of the bash process</li>
<li><code>execve()</code> to replace that new process with a copy of the desired external executable (which typically requires the OS to invoke its linker and loader to spin up a dynamic binary)</li>
<li><code>wait()</code> for that process to finish</li>
</ul>

...and, if you're capturing the output, then a FIFO needs to be created and read from as well. Thus, the very act of starting up an external tool is often much slower than that tool's time spent executing its desired function.

<hr>

That said -- if you were attentive, you may have noticed that this constructed a worst-case scenario for <code>cut</code>, processing only one line of input per invocation. Results would be very different for this:

<pre><code># for me, this is ~0.12s wall-clock
time for ((i=0; i&lt;10000; i++)); do
 printf '%s\n' 'hello:world'
done | cut -d: -f2 &gt;/dev/null
</code></pre>

...wherein only one invocation of <code>cut</code> is used for the entire stream, spreading that startup time across a very large number of lines of input.

When the job involves processing bulk input, rather than one line at a time, external tools can be more efficient when used correctly.

blocks|key|1069791|text|速度不是bash的卖点，也不是unix工具。内置的更快。也就是说，bash应该像急救箱一样使用:当你需要的时候马上使用它。如果您的脚本开始变得更加复杂，并且开始更关心速度，那么您可能应该使用更强大的工具，比如Python。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1069792|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Speed is not bash's selling point, or unix tools either. Builtins are faster. That said, bash should be used like a first-aid kit: use it when you need something now and quick. If your script starts getting more complicated and you start caring more about speed, you should probably go to something more powerful, like Python.

I'm trying to understand when it's appropriate to use "unix tools" vs BASH capabilities. Let's say for example I want to divide a string in two parts based on some delimiter. Does using "cut" invoke some kind of process/thread/external processing that is generally slower than using some other "built-in BASH utility" to divide a string in two, whatever that might be?

Are bash builtins preferable to UNIX tools for performance reasons?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我试图理解什么时候使用"unix工具“和BASH功能是合适的。例如，我想根据某个分隔符将字符串分成两部分。使用“剪切”是否调用某种进程/线程/外部处理，它通常比使用其他“内置BASH实用程序”将字符串分成两部分要慢，不管这可能是什么？

问由于性能原因，bash内置工具比UNIX工具更好吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问由于性能原因，bash内置工具比UNIX工具更好吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问由于性能原因，bash内置工具比UNIX工具更好吗？
EN