Ruby:风格和性能

Question

注意:我不知道这个问题应该放在 StackOverflow 还是 CodeReview (StackExchange) 中。如果您认为它应该在 CodeReview 中，请在评论中告诉我。

我玩 Ruby 有一段时间了。我喜欢 Ruby，因为它是一种非常漂亮且富有表现力的编程语言。最近，我也有点沉迷于性能。似乎这种痴迷让我的 Ruby 代码变得更加丑陋。这是一个非常简单的示例:返回字符的 ASCII 范围的程序(不考虑重音字符或错误处理)。

我想出了八个解决方案:

module MyProgram
  module Character
    UPPER_A = 65.freeze
    UPPER_Z = 90.freeze
    LOWER_A = 97.freeze
    LOWER_Z = 122.freeze

    module_function

    def ascii_range1(char)
      code = char.ord

      return [65, 90] if code.between?(65, 90)
      return [97, 122] if code.between?(97, 122)
    end

    def ascii_range2(char)
      code = char.ord

      if code.between?(65, 90)
        [65, 90]
      elsif code.between?(97, 122)
        [97, 122]
      end
    end

    def ascii_range3(char)
      code = char.ord

      return [65, 90] if code >= 65 && code <= 90
      return [97, 122] if code >= 97 && code <= 122
    end

    def ascii_range4(char)
      code = char.ord

      if code >= 65 && code <= 90
        [65, 90]
      elsif code >= 97 && code <= 122
        [97, 122]
      end
    end

    def ascii_range5(char)
      code = char.ord

      return [UPPER_A, UPPER_Z] if code.between?(UPPER_A, UPPER_Z)
      return [LOWER_A, LOWER_Z] if code.between?(LOWER_A, LOWER_Z)
    end

    def ascii_range6(char)
      code = char.ord

      if code.between?(UPPER_A, UPPER_Z)
        [UPPER_A, UPPER_Z]
      elsif code.between?(LOWER_A, LOWER_Z)
        [LOWER_A, LOWER_Z]
      end
    end

    def ascii_range7(char)
      code = char.ord

      return [UPPER_A, UPPER_Z] if code >= UPPER_A && code <= UPPER_Z
      return [LOWER_A, LOWER_Z] if code >= LOWER_A && code <= LOWER_Z
    end

    def ascii_range8(char)
      code = char.ord

      if code >= UPPER_A && code <= UPPER_Z
        [UPPER_A, UPPER_Z]
      elsif code >= LOWER_A && code <= LOWER_Z
        [LOWER_A, LOWER_Z]
      end
    end
  end
end

他们都做同样的事情，差异很小……我是这么认为的。例如:丑陋的表达n >= a && n <= b (本身并不难看，只是与 Ruby 的 Comparable#between? 相比)比 n.between?(a, b) 快得多.

以下是基准测试结果(使用 benchmark-ips):

Warming up --------------------------------------
                   1   134.374k i/100ms
                   2   150.861k i/100ms
                   3   215.836k i/100ms
                   4   222.775k i/100ms
                   5   150.204k i/100ms
                   6   152.013k i/100ms
                   7   220.250k i/100ms
                   8   218.256k i/100ms
Calculating -------------------------------------
                   1      2.432M (± 7.2%) i/s -     12.094M in   5.000927s
                   2      2.425M (± 6.9%) i/s -     12.069M in   5.005368s
                   3      4.142M (±11.4%) i/s -     20.504M in   5.019090s
                   4      4.442M (± 4.6%) i/s -     22.278M in   5.026760s
                   5      2.366M (± 3.0%) i/s -     11.866M in   5.019090s
                   6      2.367M (± 2.7%) i/s -     11.857M in   5.012120s
                   7      4.372M (± 3.4%) i/s -     22.025M in   5.043391s
                   8      4.367M (± 2.6%) i/s -     22.044M in   5.050882s

Comparison:
                   4:  4441965.7 i/s
                   7:  4372497.0 i/s - same-ish: difference falls within error
                   8:  4367421.3 i/s - same-ish: difference falls within error
                   3:  4141617.7 i/s - same-ish: difference falls within error
                   1:  2432164.3 i/s - 1.83x  slower
                   2:  2424708.2 i/s - 1.83x  slower
                   6:  2367435.3 i/s - 1.88x  slower
                   5:  2366400.6 i/s - 1.88x  slower

所以归结为 ascii_range3 , ascii_range4 , ascii_range7和 ascii_range8 (ascii_range4 是最快的)而我真正想要的是 ascii_range5但更快。我发现这四种方法中的任何一种都没有 ascii_range5 漂亮。 ，所以我只选择最有效的一个(通常是最丑的一个)。最近这种情况经常发生在我身上，它正在夺走我代码的美感。这让我很困扰。

请不要误解这个问题:它不是解决这个特定问题的最有效方法。它是关于如何在风格和性能之间找到完美的平衡(您可以在回答中使用这个或任何其他示例)。

谢谢。

Answer 1

how to find a perfect balance between style and performance

我完全同意 @SOFe's sentiment .

---

基本上你应该做的是:

1. 您编写了您能想到的最易读(“漂亮”)的代码，这显然并不愚蠢。
2. 如果您发现您有性能问题，您会尝试优化您的算法。
3. 如果没有进行此类优化的空间，您可以尝试在已确定存在性能问题的代码的非常有限的区域中进行此类微观性能权衡。

对于使用 Ruby 的领域，如果没有任何证据表明当前解决方案“太慢”，您永远不想尝试优化。

在现实世界中，性能瓶颈很少源于 CPU 密集使用。最常见的是数据库/网络/各种其他 I/O/等的次优使用。