【问题标题】:Interpreted vs. Compiled Languages for Web Sites (PHP, ASP, Perl, Python, etc.)网站的解释语言与编译语言(PHP、ASP、Perl、Python 等)
【发布时间】:2010-12-04 17:15:22
【问题描述】:

我建立数据库驱动的网站。以前我在 MySQL 中使用过 Perl 或 PHP。

现在我正在开始一个新的大型项目,我希望以能够产生响应速度最快的网站的方式进行。

我在这里看到了几个页面,其中有关如何优化 PHP 的问题受到各种版本的批评:“不值得花大力气优化 PHP,因为它是一种解释性语言,不会产生太大的影响”。

我还听过各种关于编译语言与解释语言的好处的讨论(尤其是 SO 播客),似乎使用编译语言提供网站而不是解释语言。

这在网络环境中是否可行?如果可以,什么是合理的语言选择?

除了速度之外,我预见到的另一个好处是可以在编译时发现错误,而不必调试网站。这是合理的预期吗?

【问题讨论】:

    标签: php webserver compiled interpreted-language


    【解决方案1】:

    您可以做的是多个大流量网站(如 Facebook 或 Twitter)所做的,也就是在 C 插件中编写您的“CPU 消耗”算法。

    例如,如果你打算使用 PHP,你可以写一个 PHP extension,或者如果你打算使用 Ruby / Ruby on Rails 等,你可以写一个 Ruby extension

    这样,您可以使您的流线型代码保持简单且易于维护(处理来自 C 的请求可能比处理来自 PHP 的请求更难),同时拥有强大而可靠的背景核心(因为它已编译,并且编译器在编译时告诉你问题是什么)

    【讨论】:

    • 如果你想进一步优化,你甚至可以编写一个 Apache 模块
    • "(因为它已经编译过了,编译器会在编译时告诉你问题出在哪里)" LOL。除非您在谈论 Ada,否则大多数其他语言都没有特别严格的编译器。此外,C 甚至没有异常处理。至少大多数脚本语言会保护您免受未定义行为的影响。
    【解决方案2】:

    如果您要构建一门新语言...并且您提出了所有语义并且它是完整的,并且您有一些魔术盒可以在编译语言和解释语言之间切换,编译版本会比解释版本更快。

    为什么?因为编译将你的语义在机器上降低到一个较低的水平,这意味着它可以更快地执行,而解释意味着你的语言的语义将被一些翻译当用户实际使用您的网站时(即解释器)。

    话虽如此……但这并不一定意味着您的网站在编译语言上的运行速度比在解释性语言上的运行速度要快 100%。如今,对于各种语言(例如 PHP),有非常快的解释器,甚至还有针对解释语言的优化器,使它们甚至更快。

    您网站的性能还有许多其他因素与您选择的语言无关。硬件设置、数据库设置、网络拓扑等。这些东西会对你产生更大的影响。我建议确定测量。

    对我来说,在编译时发现错误会大量节省时间,所以我更喜欢强类型的编译语言。它让我可以更快地完成工作,但这并不是客观上的最佳选择。有些人编写弱类型代码并在其上运行测试套件以验证其功能没有问题,我认为这也可以。

    【讨论】:

    • Quib​​ble:在解释语言上运行的 JIT 仍有可能在编译器无法进行的特定运行情况中进行一些优化,因为它们不是通用的可靠的。我有时看到一些关于 Java 的说法。因此,它成功地比编译语言更快。
    • @dmckee 我会争辩说,如果我有一个已编译的 Java 和一个 JITed Java,那么我编译的 Java 总是会运行得更快。我还没有看到这可能是错误的情况。但是,我并不是说 JITed Java 总是比编译的 C# 慢,在这种情况下,我是在比较苹果和橘子。
    • 考虑for(...){...if(cond){...}else{...}...},其中cond 已知在此运行中已修复,但通常在循环中可能是可变的。 JIT 编译器可以放弃检查并缩短循环,而通用编译器不能。我自己也从未见过这件事,但我听说过它声称。
    • 一般来说,由于机器特定的实例,JIT 应该比编译快。 JIT 可以利用机器特定指令,优化高度使用的代码路径等。我看到研究表明,JIT 的 Java 可以比编译的 C 更快,尤其是在并行代码的情况下,JIT 可以针对正确的核心数。对于像 Java 和 C# 这样的语言,JIT 应该比预编译的更快(比如 ngen,你可以提前从字节码编译到机器码),因为这些语言在设计时就考虑了 JIT。
    • @dmckee & @James 我明白你在说什么。在我亲眼目睹这一点之前,我会保留我的保留意见,尽管我绝对可以理解为什么这些场景会为 JIT 产生比经典编译更好的结果。
    【解决方案3】:

    恕我直言,使用编译语言编写复杂的 Web 应用程序是完全没有意义的,因为它对许多可管理性问题没有好处。

    有很多方法可以提高脚本语言的性能和可扩展性,无论是在语言级别还是在系统级别,最终通过完全有影响力的编译语言获得较小的性能增益。

    另一方面,我发现遵循敏捷开发和错误搜寻模式非常有用,只需更改代码并查看结果即可。

    【讨论】:

      【解决方案4】:

      Perl 不是解释型语言:它被编译为字节码,因此只有在 perl 可执行文件启动时,您才需要为解释付出代价。所以在 Apache 中使用它时,不要使用 CGI,而是使用 mod_perl。

      无论您做什么,如果您选择的语言不适合 Web 编程或没有好的库来支持您需要做的事情,那么开发时间可能会大大超过响应时间。例如。我永远不会选择 C ​​或 C++。您不想要一个速度极快但有缺陷且延迟 6 个月的网络应用。

      【讨论】:

      • 在虚拟机上运行与在硬件上运行仍然不完全相同。当然它比连续解析程序文本要快,但仍然......它是纯解释和本机代码之间的中间情况。
      • PHP 和 Perl 一样,被编译成字节码。默认情况下,它是在每次加载时完成的,但您可以使用操作码缓存来解决这个问题。
      【解决方案5】:

      Tomcat 是使用编译语言部署网页的常用方法,但在你走得太远之前,请认真考虑你的速度瓶颈会是什么。 Web 应用程序速度变慢的主要原因有几个:

      1. 网络延迟
      2. 静态媒体,尤其是图片
      3. 数据库查询
      4. 服务器端处理代码
      5. 客户端处理代码

      1 和 5 与这个问题没有太大关系。

      如果您有许多图像因页面而异,2 将是相关的。如果是这种情况,客户端浏览器的缓存就不会那么好,并且每次页面加载都需要一些时间。在这种情况下,您的服务器端语言很可能不会被注意到,因为静态媒体的开销将占主导地位。

      对于许多应用程序来说,3 可能比 4 更大。如果你的数据很少,但你做了很多处理,那么 4 可能会占主导地位,否则,即使你使用的是解释性语言,3 也会占主导地位。

      人们可能会问“为什么要优化 php?”因为无论如何,2和3通常更重要。通常,一个好的 database caching framework 会是一个更好(也更容易)的优化。

      【讨论】:

        【解决方案6】:

        Web 应用程序中有很多部分。应用层所花费的时间不需要很大。对于一个典型的应用程序,最大的麻烦是在网络服务器和数据库中。用二进制 cgi 替换 PHP 不会改变这一点。

        此外,虽然 PHP 的解释部分可能有点慢,但这只是 PHP 脚本执行过程中的一小部分。作为语言的一部分提供的所有功能都以本机代码实现。例如,当你调用像preg_match 这样的函数时,它会调用一个本机代码库并让它工作。这意味着发生的实际解释比您想象的要少。

        在某些情况下,使用与 PHP 不同的语言可能是值得的,但这些都是特殊情况。一般来说,这里没有任何收获。

        【讨论】:

          【解决方案7】:

          到目前为止,网络的延迟是这个论点的最大决定因素。事实上,网络延迟是一个非常重要的因素,它使得语言考虑因素在性能问题上变得相当不重要。所以……用你所知道的。使用您最舒适和最有效率的语言,并且可以在您进行过程中解决其他注意事项。现在,也就是说,尝试新事物总是很有趣,学习新事物可能会成为一种痴迷,所以如果这个项目是一个让你有机会进行实验的个人项目,那么,无论如何......

          【讨论】:

          • 感谢您的回答,但我不确定我是否同意。如果我同时有一百个访问者使用我的服务器的 CPU,那么执行速度与否都会产生很大的不同。在多次听说 PHP 很慢后,我问了这个问题。根据我的经验,与数据库问题相比,PHP 的速度几乎没有影响——糟糕的 MySQL 设计真的会减慢一切。
          猜你喜欢
          • 2011-03-16
          • 1970-01-01
          • 1970-01-01
          • 2016-11-24
          • 1970-01-01
          • 2010-09-06
          • 2021-01-15
          • 2011-02-09
          • 1970-01-01
          相关资源
          最近更新 更多