网站的解释语言与编译语言（PHP、ASP、Perl、Python 等）
我构建数据库驱动的网站。以前我曾将 Perl 或 PHP 与 MySQL 一起使用。
现在我正在开始一个大型的新项目，我希望以能够产生响应速度最快的网站的方式来完成它。
我在这里看到了几个页面，其中有关如何优化 PHP 的问题受到各种版本的批评，“不值得花很大力气来优化 PHP，因为它是一种解释性语言，不会产生太大的影响”。
我还听到了关于编译语言与解释语言的好处的各种讨论（特别是在 SO 播客上），并且似乎使用编译语言来提供服务符合我的利益。网站而不是解释性语言。
这在网络环境中是否可能？如果可以，合理的语言选择是什么？
除了速度之外，我预见到的一个好处是可以在编译时查找错误，而不必调试网站。这是合理的预期吗？
I build database-driven web sites. Previously I have used Perl or PHP with MySQL.
Now I am starting a big new project, and I want to do it in the way that will result in the most responsive possible site.
I have seen several pages here where questions about how to optimize PHP are criticized with various versions of "it's not worth going to great lengths to optimize PHP since it's an interpreted language and it won't make that much difference".
I have also heard various discussions (especiallon on the SO podcast) about the benefits of compiled vs. interpreted languages, and it seems as though it would be in my interests to use a compiled language to serve up the site instead of an interpreted language.
Is this even possible in a web context? If so, what would be a reasonable language choice?
In addition to speed one benefit I forsee is the possiblity of finding bugs at compile time instead of having to debug the web site. Is this reasonable to expect?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您可以做的就是多个大流量网站（例如 Facebook 或 Twitter）所做的事情，也就是在 C 插件中编写“CPU 消耗”算法。
例如，如果您计划使用 PHP，则可以编写 PHP 扩展，或者 Ruby 扩展 如果您计划使用 Ruby / Ruby on Rails 等。
这样，您可以保持精简代码简单且易于维护（处理来自 C 的请求可能比处理来自 PHP 的请求困难得多），同时拥有强大而坚实的后台核心（因为它是编译过的，编译器会在编译时告诉您问题是什么）
What you can do is what multiple heavy-traffic websites do (like Facebook or Twitter), aka write your "CPU consuming" algorythm in a C-plugin.
For example, you could write a PHP extension if you plan to use PHP, or a Ruby extension if you plan to use Ruby / Ruby on Rails, etc.
That way, you can keep your streamline code simple and easy to maintain (it might be way harder to handle request from C rather than from PHP), while having a strong and solid background core (because it's compiled, and the compiler tells you what the issues are at compile time)
如果你要构建一种新语言......并且你想出了所有语义并且它是完整的，并且你有一些魔盒可以在编译语言和解释语言之间进行切换，编译版本会更快比解释版本。
为什么？因为编译将您的语义降低到机器上的较低级别，这意味着它可以更快地执行，而解释意味着您的语言的语义将被某些翻译当用户实际使用您的网站时的东西（即解释器）。
话虽如此……这并不一定意味着您的网站在编译语言上比在解释语言上运行速度将 100% 更快。现在有一些解释器对于各种语言（例如 PHP）来说都非常快，甚至还有针对解释性语言的优化器，可以使它们更快。
还有许多其他因素会影响您网站的性能，而这些因素与您选择的语言无关。硬件设置、数据库设置、网络拓扑等。这些事情会对你产生更大的影响。我建议进行测量以确定。
对我来说，在编译时查找错误可以节省巨大时间，因此我倾向于更喜欢强类型的编译语言。它可以让我更快地完成工作，但这并不意味着它客观上是最佳选择。有些人可以毫无问题地编写弱类型代码，并在其上运行测试套件来验证其功能，我认为这也可以。
If you were going to build a new language... and you came up with all the semantics and it was complete, and you had some magic box that had a switch between making the language compiled vs. interpreted, the compiled version would be faster than the interpreted version.
Why? Because compiling brings your semantics down to a lower level on the machine which means it can executed much faster, whereas interpreting means the semantics of your language will translated by some thing (i.e. the interpreter) when the user actually uses your site.
Having said that... that doesn't necessarily mean that your site is going to 100% run faster on a compiled language vs an interpreted language. There are interpreters out there that are very fast nowadays for various languages (i.e. PHP), and there are even optimizers for interpreted languages that make them faster even still.
There are many other things that go into the performance of your site that are agnostic of the language you choose. Hardware setup, Database setup, Network topology, etc. These things can have a bigger impact on you. I would suggest measuring to be sure.
For me, finding bugs at compile time is a huge time saver, so I tend to prefer compiled languages which are strongly typed. It lets me get my work done faster, but that doesn't make it objectively the best option. Some people have no issue writing weakly typed code, and running test suites on them to verify their functionality, which I would think would work just as well.
恕我直言，使用编译语言编写复杂的 Web 应用程序是完全没有意义的，因为它并不能解决许多可管理性问题。
有很多方法可以提高脚本语言的性能和可扩展性，无论是在语言级别还是在系统级别，最终都可以通过具有完全影响力的编译语言获得较小的性能提升。
另一方面，我发现遵循敏捷开发和错误搜寻模式非常有用，只需更改代码并查看结果即可。
IMHO it is quite a non-sense to write a complex web app using a compiled language, as it gives not benefits against a number of manageability problems.
There a lot of ways to rise up performances and scalability in a scripted language, both at language level and at system level, being the minor performances gain eventually available with a compiled language totally influential.
On the other side I find very useful to be possible to follow an agile development and bug hunting schema, simply changing your code and seeing the results.
Perl 不是解释性语言：它被编译为字节码，因此只有在启动 perl 可执行文件时才需要付出解释的代价。因此，当与 Apache 一起使用时，不要使用 CGI，而应使用 mod_perl。
无论您做什么，如果您选择的语言不适合 Web 编程或者没有良好的库来支持您需要执行的操作，那么开发时间可能会大大超过响应时间。例如，我永远不会选择 C 或 C++。您不想要一个速度极快但有 bug 且延迟 6 个月的 Web 应用程序。
Perl isn't an interpreted language: it is compiled to bytecode, so you pay the price of interpretation only when the perl executable is started. So when using it with Apache, don't use CGI but mod_perl.
Whatever you do, development time is probably going to widely exceed response time if you pick a language that isn't suitable to web programming or doesn't have good libraries to support what you need to do. E.g. I'd never pick C or C++. You don't want a web app that is blisteringly fast but buggy and 6 months late.
Tomcat 是使用编译语言部署网页的常用方法，但在走得太远之前，请认真考虑一下< em>你的速度瓶颈是什么。 Web 应用程序速度减慢有几个主要来源：
1 和 5 与这个问题没有太大关系。
如果您有许多页面不同的图像，则 2 将是相关的。如果是这种情况，客户端浏览器将无法很好地进行缓存，并且每个页面加载都将花费一些时间。在这种情况下，您的服务器端语言很可能不会被注意到，因为静态媒体的开销将占主导地位。
对于很多应用来说，3 可能是比 4 更大的因数。如果您的数据很少，但进行了大量处理，那么 4 可能会占主导地位，但除此之外，即使您使用解释型语言，3 也会占主导地位。
人们可能会问“为什么要优化 php？”因为无论如何，2 和 3 通常更重要。通常，一个好的数据库缓存框架将是更好（也更容易）的优化。
Tomcat is a common way to use compiled languages to deploy webpages, but before you go too far, seriously consider what your speed bottlenecks will be. There are a few main sources of slowdown in web applications:
1 and 5 don't really have much to do with this question.
2 will be relevant if you have many images that vary from page to page. If that's the case, client browsers won't do such a good job caching, and each page-load will take some time. In this case, it is very likely that your server-side language won't be noticed, because the overhead from static media will dominate.
3 is likely to be a bigger factor than 4 for a lot of applications. If you have very little data, but you do a whole lot of processing, then 4 may dominate, but otherwise, 3 will dominate even if you're using an interpreted language.
People can ask "Why optimize php?" because the 2 and 3 are often more important anyway. Often, a good database caching framework is going to be a better (and easier) optimization.
Web 应用程序包含很多部分。应用层花费的时间不需要很大。对于典型的应用程序，最大的消耗量将在网络服务器和数据库中。用二进制 cgi 替换 PHP 不会改变这一点。
此外，虽然 PHP 的解释部分可能有点慢，但这只是 PHP 脚本执行过程中的一小部分。作为语言一部分提供的所有功能均以本机代码实现。例如，当您调用像
preg_match这样的函数时，它会调用本机代码库并让它完成其工作。这意味着实际的解释比您想象的要少。在某些情况下，使用 PHP 之外的语言可能是值得的，但这些都是特殊情况。一般来说，在这里没有什么收获。
There are lots of parts that goes into a web application. The time taken by the application layer doesn't need to be big. For a typical application, the biggest hogs would be in the webserver and in the database. Replacing PHP with a binary cgi isn't going to change this.
Furthermore, while the interpreted parts of PHP may be somewhat slow, that is only a small part of what goes on in the execution of a PHP script. All the functions that are provided as part of the language are implemented in native code. For example, when you call a function like
preg_match, it will call out a native code library and let it do its work. This means that there is less actual interpretation going on than you might think.There may be some cases where using a different language than PHP might be worthwhile, but those are special cases. In general, there is nothing to gain here.
网络延迟是迄今为止这场争论中最大的决定因素。事实上，网络延迟是一个非常重要的因素，它使得语言考虑因素与性能问题相比变得不那么重要。所以...按照你所知道的去做。使用您最熟悉、最有效率的语言，并且可以在您进行过程中考虑其他注意事项。现在，也就是说，尝试新事物总是很有趣，并且学习新事物可能会成为一种痴迷，所以如果该项目是个人项目，让您有机会进行实验，那么，无论如何......
The latency of the network is by far the greatest determining factor in this argument. In fact, network latency is so much of a factor that it renders language considerations rather unimportant from a performance issue. So...go with what you know. Use the language that you are most comfortable and most productive with and other considerations can be worked out as you go along. Now, that said, it's always fun to try new stuff and learning new things can become an obsession, so if the project is a personal one that allows you the opportunity to experiment, well, by all means.....