您还可以查看跨平台框架，例如 gtk、wxWidgets 和 Qt。 虽然它们针对的是 GUI，但它们确实具有低级跨平台数据类型和网络库，可以使使用基于快速 C 的应用程序的工作变得更容易。
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
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.
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.
"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.
Rather than restarting, you're just processing another request. You get to keep as much state as you need to optimize performance.
考虑到执行时间和内存成本，我怀疑您是否可以比使用任何脚本语言正确编写的 C 更快，因为您至少会在解释脚本上损失一些时间......
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.
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...
我同意 Lua：它是超级可移植的，它有 XML 库，可以是原生的，也可以通过绑定 C 库（如 Expat），它有一个很好的套接字库（LuaSocket），另外，用于复杂的东西，一些 cURL 绑定，并且众所周知非常轻量级（通常嵌入在低内存设备中）、非常快（最快的脚本语言之一）并且功能强大。 并且非常容易编码！
它是用纯 Ansi C 编写的，很多人声称它拥有最好的 C 投标 API 之一（从 Lua 调用 C 例程，从 C 调用 Lua 代码......）。
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!
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...).
这有点个人的事情。 Ruby 编程让我很开心，而 C 代码则不然（对于任何重要的事情，bash 脚本也不是）。
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.
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.
It is a bit of a personal thing. Programming Ruby makes me happy, C code does not (nor bash scripting for anything non-trivial).
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
（Perl 解释器的参数加载相当大的 CGI 模块，然后执行代码行“0;”。）
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.
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.
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;'.)
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.
I agree with others in that you should probably try to make this a more portable C app instead of porting it over to something else since any scripting language is going to introduce significant overhead from a startup perspective, have a much larger memory footprint, and will probably be much slower.
In my experience, Python is the most efficient of the three, followed by Perl and then Ruby with the difference between Perl and Ruby being particularly large in certain areas. If you really want to try porting this to a scripting language, I would put together a prototype in the language you are most comfortable with and see if it comes close to your requirements. If you don't have a preference, start with Python as it is easy to learn and use and if it is too slow with Python, Perl and Ruby probably won't be able to do any better.
Remember that if you choose Python, you can also extend it in C if the performance isn't great. Heck, you could probably even use some of the code you have right now. Just recompile it and wrap it using pyrex.
You can also do this fairly easily in Ruby, and in Perl (albeit with some more difficulty). Don't ask me about ways to do this though.
Can you instead have it be a long-running process and answer http or rpc requests? This would satisfy the latency requirements in almost any scenario, but I don't know if that would break your memory footprint constraints.
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?).
Some libraries can help you to make your code portable: Boost, Qt
发布评论
评论（13）
Lua 是一种符合您标准的脚本语言。 它无疑是可用的最快且内存最低的脚本语言。
Lua is a scripting language that meets your criteria. It's certainly the fastest and lowest memory scripting language available.
由于您对快速启动时间和大于 1Hz 的调用频率的要求，我建议要么继续使用 C 并弄清楚如何使其可移植（并不总是像一些 ifdef 那样容易），要么探索将其变成一个始终运行的服务守护进程。 当然，这取决于
如果编译模块并运行 .pyc 文件，Python 如何具有较低的启动时间，但通常仍然被认为很慢。 根据我的经验，Perl 是最快的脚本语言，因此您可能会很幸运地使用 Perl 守护程序。
您还可以查看跨平台框架，例如 gtk、wxWidgets 和 Qt。 虽然它们针对的是 GUI，但它们确实具有低级跨平台数据类型和网络库，可以使使用基于快速 C 的应用程序的工作变得更容易。
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
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.
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.
“从每分钟到每秒调用多次。因此，保持较低的内存和启动时间非常重要。”
对我来说，这听起来根本不像剧本。
这听起来像是服务器处理每分钟到每秒几次到达的请求。
如果它是一个服务器，处理请求，启动时间并不像响应能力那么重要。 在这种情况下，Python 可能会表现良好，并且仍然保持性能。
您只是在处理另一个请求，而不是重新启动。 您可以保留优化性能所需的尽可能多的状态。
"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.
Rather than restarting, you're just processing another request. You get to keep as much state as you need to optimize performance.
如果编写得当，C 应该是平台无关的，并且只需要针对这些不同的平台重新编译。 您可能必须跳过一些标头的 #ifdef 环（并非所有系统都使用相同的标头），但大多数普通（非 win32 API）调用都非常可移植。
对于网络访问（我认为您提到 bash+curl 时需要），您可以看一下 libcurl，它适用于您提到的所有平台，并且使用起来应该不难。
考虑到执行时间和内存成本，我怀疑您是否可以比使用任何脚本语言正确编写的 C 更快，因为您至少会在解释脚本上损失一些时间......
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.
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...
我同意 Lua：它是超级可移植的，它有 XML 库，可以是原生的，也可以通过绑定 C 库（如 Expat），它有一个很好的套接字库（LuaSocket），另外，用于复杂的东西，一些 cURL 绑定，并且众所周知非常轻量级（通常嵌入在低内存设备中）、非常快（最快的脚本语言之一）并且功能强大。 并且非常容易编码！
它是用纯 Ansi C 编写的，很多人声称它拥有最好的 C 投标 API 之一（从 Lua 调用 C 例程，从 C 调用 Lua 代码......）。
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!
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...).
如果低内存和低启动时间确实很重要，您可能需要考虑保持 C 代码跨平台，但我发现这很少有必要。
就我个人而言，我会使用 Ruby 或 Python 来完成此类工作，它们都可以非常轻松地编写清晰易懂的代码，以便其他人可以维护（或者您可以在 6 个月不看代码后进行维护）。 如果您有能力这样做，我还建议您获取最新版本的解释器，因为 Ruby 和 Python 最近在性能方面都取得了显着的改进。
这有点个人的事情。 Ruby 编程让我很开心，而 C 代码则不然（对于任何重要的事情，bash 脚本也不是）。
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.
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.
It is a bit of a personal thing. Programming Ruby makes me happy, C code does not (nor bash scripting for anything non-trivial).
正如其他人所建议的，对脚本进行守护进程可能是一个好主意； 这会将启动时间减少到几乎为零。 要么有一个小的 C 包装器连接到您的守护进程并来回传输请求，要么让守护进程直接处理请求。
目前还不清楚这是否是为了处理 HTTP 请求； 如果是这样，Perl 有一个很好的 HTTP 服务器模块，绑定到几个不同的基于 C 的 XML 解析器，并且支持极快的字符串。 （如果您不想守护进程，它有一个很好的、功能齐全的 CGI 模块；如果您可以完全控制它运行的服务器，您还可以使用 mod_perl 将脚本实现为 Apache 处理程序。） Ruby 的字符串有点慢，但是有一些非常好的后台工具可用。 恐怕我对 Python 不太熟悉，所以我不能真正提出任何关于它的建议。
但总的来说，我认为你的启动时间并不像你想象的那么有限。 如果脚本确实每秒被调用几次，那么任何像样的操作系统上的任何像样的解释器都将被缓存在内存中，脚本及其模块的源代码也将被缓存在内存中。 结果：启动时间不会像您想象的那么糟糕。
（Perl 解释器的参数加载相当大的 CGI 模块，然后执行代码行“0;”。）
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.
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.
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.
(The parameters to the Perl interpreter load the rather large CGI module and then execute the line of code '0;'.)
Python 很好。 我还会查看计算机语言基准游戏网站：
http://shootout.alioth.debian.org/< /a>
花一些时间了解基准测试（包括启动时间和内存使用情况的数字）可能是值得的。 比较了许多语言，例如 Perl、Python、Lua 和 Ruby。 您还可以将这些语言与 C 中的基准进行比较。
Python is good. I would also check out The Computer Languages Benchmarks Game website:
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.
我同意其他人的观点，您可能应该尝试使其成为一个更可移植的 C 应用程序，而不是将其移植到其他应用程序，因为从启动的角度来看，任何脚本语言都会引入显着的开销，具有更大的内存占用，并且将可能会慢得多。
根据我的经验，Python 是三者中效率最高的，其次是 Perl，然后是 Ruby，Perl 和 Ruby 在某些方面的差异特别大。 如果您确实想尝试将其移植到脚本语言，我会用您最熟悉的语言构建一个原型，看看它是否接近您的要求。 如果您没有偏好，请从 Python 开始，因为它很容易学习和使用，如果 Python 太慢，Perl 和 Ruby 可能无法做得更好。
I agree with others in that you should probably try to make this a more portable C app instead of porting it over to something else since any scripting language is going to introduce significant overhead from a startup perspective, have a much larger memory footprint, and will probably be much slower.
In my experience, Python is the most efficient of the three, followed by Perl and then Ruby with the difference between Perl and Ruby being particularly large in certain areas. If you really want to try porting this to a scripting language, I would put together a prototype in the language you are most comfortable with and see if it comes close to your requirements. If you don't have a preference, start with Python as it is easy to learn and use and if it is too slow with Python, Perl and Ruby probably won't be able to do any better.
请记住，如果您选择 Python，如果性能不是很好，您也可以使用 C 对其进行扩展。 哎呀，您甚至可以使用您现在拥有的一些代码。 只需重新编译它并使用 pyrex 包装它即可。
您也可以在 Ruby 和 Perl 中相当轻松地完成此操作（尽管有一些困难）。 不过，不要问我如何做到这一点。
Remember that if you choose Python, you can also extend it in C if the performance isn't great. Heck, you could probably even use some of the code you have right now. Just recompile it and wrap it using pyrex.
You can also do this fairly easily in Ruby, and in Perl (albeit with some more difficulty). Don't ask me about ways to do this though.
您能否让它成为一个长时间运行的进程并回答 http 或 rpc 请求？
这几乎可以满足任何情况下的延迟要求，但我不知道这是否会打破您的内存占用限制。
Can you instead have it be a long-running process and answer http or rpc requests?
This would satisfy the latency requirements in almost any scenario, but I don't know if that would break your memory footprint constraints.
乍一看，这听起来像是过度工程，根据经验，我建议仅在出现问题时才进行修复。
您有一个已经可以运行的应用程序。 显然您想要调用从多个来源提供的功能。 对我来说，它看起来像是服务的描述（也许更容易维护）。
最后您还提到这是一个更大解决方案的一部分，那么您可能想重用更大解决方案的语言、设施。 从您给出的描述（xml+http）来看，它似乎是一个非常常见的应用程序，可以用任何通用语言编写（也许是java中的Web容器？）。
一些库可以帮助您使代码可移植：
提升，
Qt
更多细节可能会引发更多想法:)
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?).
Some libraries can help you to make your code portable:
Boost,
Qt
more details may trigger more ideas :)
将您的应用程序移植到 Ruby。 如果您的应用程序太慢，请分析它并用 C 重写这些部分。
Port your app to Ruby. If your app is too slow, profile it and rewrite the those parts in C.