bash 初始性能的脚本语言选择

Scripting language choice for initial performance

提问by Chris Dail

I have a small lightweight application that is used as part of a larger solution. Currently it is written in C but I am looking to rewrite it using a cross-platform scripting language. The solution needs to run on Windows, Linux, Solaris, AIX and HP-UX.

我有一个小型轻量级应用程序，用作更大解决方案的一部分。目前它是用 C 编写的，但我希望使用跨平台脚本语言来重写它。该解决方案需要在 Windows、Linux、Solaris、AIX 和 HP-UX 上运行。

The existing C application works fine but I want to have a single script I can maintain for all platforms. At the same time, I do not want to lose a lot of performance but am willing to lose some.

现有的 C 应用程序工作正常，但我想要一个可以为所有平台维护的脚本。同时，我不想失去很多表现，但愿意失去一些。

Startup cost of the script is very important. This script can be called anywhere from every minute to many times per second. As a consequence, keeping it's memory and startup time low are important.

脚本的启动成本非常重要。该脚本可以从每分钟到每秒多次调用。因此，保持较低的内存和启动时间很重要。

So basically I'm looking for the best scripting languages that is:

所以基本上我正在寻找最好的脚本语言：

• Cross platform.
• Capable of XML parsing and HTTP Posts.
• Low memory and low startup time.

• 跨平台。
• 能够进行 XML 解析和 HTTP Posts。
• 低内存和低启动时间。

Possible choices include but are not limited to: bash/ksh + curl, Perl, Python and Ruby. What would you recommend for this type of a scenario?

可能的选择包括但不限于：bash/ksh + curl、Perl、Python 和 Ruby。对于这种类型的场景，您有什么建议？

采纳答案by Brian C. Lane

Because of your requirement for fast startup time and a calling frequency greater than 1Hz I'd recommend either staying with C and figuring out how to make it portable (not always as easy as a few ifdefs) or exploring the possibility of turning it into a service daemon that is always running. Of course this depends on how

由于您需要快速启动时间和大于 1Hz 的调用频率，我建议您继续使用 C 并弄清楚如何使其可移植（并不总是像几个 ifdef 那样容易）或探索将其变成一个始终运行的服务守护进程。当然这取决于如何

Python can have lower startup times if you compile the module and run the .pyc file, but it is still generally considered slow. Perl, in my experience, in the fastest of the scripting languages so you might have good luck with a perl daemon.

如果编译模块并运行 .pyc 文件，Python 的启动时间可能会更短，但通常仍被认为很慢。根据我的经验，Perl 是最快的脚本语言，因此您可能会在使用 perl 守护程序时好运。

You could also look at cross platform frameworks like gtk, wxWidgets and Qt. While they are targeted at GUIs they do have low level cross platform data types and network libraries that could make the job of using a fast C based application easier.

您还可以查看跨平台框架，例如 gtk、wxWidgets 和 Qt。虽然它们是针对 GUI 的，但它们确实具有低级别的跨平台数据类型和网络库，可以使使用基于 C 的快速应用程序的工作变得更容易。

回答by Luey Luow

Lua is a scripting language that meets your criteria. It's certainly the fastest and lowest memory scripting language available.

Lua 是一种符合您标准的脚本语言。它当然是可用的最快和最低内存的脚本语言。

回答by S.Lott

"called anywhere from every minute to many times per second. As a consequence, keeping it's memory and startup time low are important."

“从每分钟到每秒多次调用。因此，保持较低的内存和启动时间很重要。”

This doesn't sound like a script to me at all.

这对我来说根本不像是剧本。

This sounds like a server handling requests that arrive from every minute to several times a second.

这听起来像是处理从每分钟到每秒数次到达的请求的服务器。

If it's a server, handling requests, start-up time doesn't mean as much as responsiveness. In which case, Python might work out well, and still keep performance up.

如果它是一个服务器，处理请求，启动时间并不意味着响应能力。在这种情况下，Python 可能运行良好，并且仍然保持性能。

Rather than restarting, you're just processing another request. You get to keep as much state as you need to optimize performance.

您只是在处理另一个请求，而不是重新启动。您可以根据需要保留尽可能多的状态以优化性能。

回答by Frans-Willem

When written properly, C should be platform independant and would only need a recompile for those different platforms. You might have to jump through some #ifdef hoops for the headers (not all systems use the same headers), but most normal (non-win32 API) calls are very portable. For web access (which I presume you need as you mention bash+curl), you could take a look at libcurl, it's available for all the platforms you mentioned, and shouldn't be that hard to work with.

如果编写得当，C 应该是平台无关的，并且只需要为那些不同的平台重新编译。您可能需要跳过一些#ifdef 圈以获得标头（并非所有系统都使用相同的标头），但大多数普通（非 win32 API）调用是非常便携的。对于网络访问（我认为您在提到 bash+curl 时需要这样做），您可以查看 libcurl，它可用于您提到的所有平台，并且不应该很难使用。

With execution time and memory cost in mind, I doubt you could go any faster than properly written C with any scripting language as you would lose at least some time on interpreting the script...

考虑到执行时间和内存成本，我怀疑您是否可以比使用任何脚本语言正确编写的 C 更快，因为您至少会在解释脚本时浪费一些时间......

回答by PhiLho

I concur with Lua: it is super-portable, it has XML libraries, either native or by binding C libraries like Expat, it has a good socket library (LuaSocket) plus, for complex stuff, some cURL bindings, and is well known for being very lightweight (often embedded in low memory devices), very fast (one of the fastest scripting languages), and powerful. And very easy to code!

我同意 Lua：它是超级可移植的，它有 XML 库，可以是原生的，也可以是通过绑定 C 库（如 Expat），它有一个很好的套接字库 (LuaSocket) 加上，对于复杂的东西，一些 cURL 绑定，并且众所周知非常轻巧（通常嵌入在低内存设备中）、速度非常快（最快的脚本语言之一）且功能强大。并且非常容易编码！

It is coded in pure Ansi C, and lot of people claim it has one of the best C biding API (calling C routines from Lua, calling Lua code from C...).

它是用纯 Ansi C 编码的，很多人声称它拥有最好的 C 投标 API 之一（从 Lua 调用 C 例程，从 C 调用 Lua 代码......）。

回答by csexton

If Low memory and low startup time are truly important you might want to consider doing the work to keep the C code cross platform, however I have found this is rarely necessary.

如果低内存和低启动时间真的很重要，您可能需要考虑做保持 C 代码跨平台的工作，但是我发现这很少有必要。

Personally I would use Ruby or Python for this type of job, they both make it very easy to make clear understandable code that others can maintain (or you can maintain after not looking at it for 6 months). If you have the control to do so I would also suggest getting the latest version of the interpreter, as both Ruby and Python have made notable improvements around performance recently.

就我个人而言，我会使用 Ruby 或 Python 来完成这种类型的工作，它们都可以很容易地编写其他人可以维护的清晰易懂的代码（或者您可以在 6 个月不看它后进行维护）。如果您可以控制这样做，我还建议您获取最新版本的解释器，因为 Ruby 和 Python 最近都在性能方面取得了显着改进。

It is a bit of a personal thing. Programming Ruby makes me happy, C code does not (nor bash scripting for anything non-trivial).

这有点私人的东西。Ruby 编程让我很开心，C 代码不会（也不是 bash 脚本的任何非平凡的东西）。

回答by Nelson

Python is good. I would also check out The Computer Languages Benchmarks Game website:

蟒蛇不错。我还会查看计算机语言基准游戏网站：

http://shootout.alioth.debian.org/

http://shootout.alioth.debian.org/

It might be worth spending a bit of time understanding the benchmarks (including numbers for startup times and memory usage). Lots of languages are compared such as Perl, Python, Lua and Ruby. You can also compare these languages against benchmarks in C.

可能值得花一些时间了解基准测试（包括启动时间和内存使用量的数字）。许多语言进行了比较，例如 Perl、Python、Lua 和 Ruby。您还可以将这些语言与 C 中的基准进行比较。

回答by Brent Royal-Gordon

As others have suggested, daemonizing your script might be a good idea; that would reduce the startup time to virtually zero. Either have a small C wrapper that connects to your daemon and transmits the request back and forth, or have the daemon handle requests directly.

正如其他人所建议的，守护您的脚本可能是一个好主意；这会将启动时间减少到几乎为零。要么有一个小的 C 包装器连接到您的守护程序并来回传输请求，要么让守护程序直接处理请求。

It's not clear if this is intended to handle HTTP requests; if so, Perl has a good HTTP server module, bindings to several different C-based XML parsers, and blazing fast string support. (If you don't want to daemonize, it has a good, full-featured CGI module; if you have full control over the server it's running on, you could also use mod_perl to implement your script as an Apache handler.) Ruby's strings are a little slower, but there are some really good backgrounding tools available for it. I'm not as familiar with Python, I'm afraid, so I can't really make any recommendations about it.

不清楚这是否是为了处理 HTTP 请求；如果是这样，Perl 有一个很好的 HTTP 服务器模块，绑定到几个不同的基于 C 的 XML 解析器，以及极快的字符串支持。（如果你不想守护进程，它有一个很好的、功能齐全的 CGI 模块；如果你可以完全控制它运行的服务器，你也可以使用 mod_perl 将你的脚本实现为 Apache 处理程序。）Ruby 的字符串有点慢，但有一些非常好的背景工具可用。恐怕我对 Python 不太熟悉，所以我无法真正提出任何建议。

In general, though, I don't think you're as startup-time-constrained as you think you are. If the script is really being called several times a second, any decent interpreter on any decent operating system will be cached in memory, as will the source code of your script and its modules. Result: the startup times won't be as bad as you might think.

不过，总的来说，我认为您的启动时间并不像您想象的那样受限制。如果脚本真的每秒被调用几次，那么任何体面的操作系统上的任何体面的解释器都将缓存在内存中，您的脚本及其模块的源代码也是如此。结果：启动时间不会像您想象的那么糟糕。

Dagny:~ brent$ time perl -MCGI -e0

real    0m0.610s
user    0m0.036s
sys     0m0.022s
Dagny:~ brent$ time perl -MCGI -e0

real    0m0.026s
user    0m0.020s
sys     0m0.006s

(The parameters to the Perl interpreter load the rather large CGI module and then execute the line of code '0;'.)

（Perl 解释器的参数加载相当大的 CGI 模块，然后执行代码 '0;' 行。）

回答by call me Steve

At first sight, it's sounds like over engineering, as a rule of thumb I suggest fixing only when things are broken.

乍一看，这听起来像是过度工程化，根据经验，我建议仅在出现问题时才进行修复。

You have an already working application. Apparently you want to want to call the feature provided from few more several sources. It looks like the description of a service to me (maybe easier to maintain).

您有一个已经可以运行的应用程序。显然，您想要调用从多个来源提供的功能。它看起来像是对我的服务描述（也许更容易维护）。

Finally you also mentioned that this is part of a larger solution, then you may want to reuse the language, facilities of the larger solutions. From the description you gave (xml+http) it seems quite an usual application that can be written in any generalist language (maybe a web container in java?).

最后您还提到这是更大解决方案的一部分，那么您可能希望重用更大解决方案的语言和设施。从您给出的描述 (xml+http) 来看，它似乎是一个可以用任何通用语言编写的常见应用程序（也许是 java 中的 Web 容器？）。

Some libraries can help you to make your code portable: Boost, Qt

一些库可以帮助您使代码具有可移植性： Boost、 Qt

more details may trigger more ideas :)

更多的细节可能会引发更多的想法:)

回答by Clint Pachl

Port your app to Ruby. If your app is too slow, profile it and rewrite the those parts in C.

将您的应用程序移植到 Ruby。如果您的应用程序太慢，请对其进行分析并用 C 重写这些部分。