python - 尝试/捕捉或验证速度？

Question

我正在使用 Python，每当我必须验证函数输入时，我都会假设输入有效，然后发现错误。

在我的例子中，我有一个通用的 Vector() 类，我用它来做一些不同的事情，其中​​之一就是加法。它既可用作 Color() 类，也可用作 Vector()，因此当我向 Color() 添加标量时，它应该将该常量添加到每个单独的组件中。 Vector() 和 Vector() 添加需要按组件添加。

此代码用于光线追踪器，因此任何速度提升都很棒。

这是我的 Vector() 类的简化版本:

class Vector:
  def __init__(self, x, y, z):
    self.x = x
    self.y = y
    self.z = z

  def __add__(self, other):
    try:
      return Vector(self.x + other.x, self.y + other.y, self.z + other.z)
    except AttributeError:
      return Vector(self.x + other, self.y + other, self.z + other)

我目前正在使用 try...except 方法。有人知道更快的方法吗？

---

编辑:感谢答案，我尝试并测试了以下解决方案，该解决方案在添加 Vector() 对象之前专门检查类名:

class Vector:
  def __init__(self, x, y, z):
    self.x = x
    self.y = y
    self.z = z

  def __add__(self, other):
    if type(self) == type(other):
      return Vector(self.x + other.x, self.y + other.y, self.z + other.z)
    else:
      return Vector(self.x + other, self.y + other, self.z + other)

---

我使用 timeit 对这两个代码块进行了速度测试，结果非常显着:

 1.0528049469 usec/pass for Try...Except
 0.732456922531 usec/pass for If...Else
 Ratio (first / second): 1.43736090753

我还没有使用 no 输入验证测试 Vector() 类(即将 checkout 类移到实际代码中)，但我'会想象它比 if...else 方法更快。

---

延迟更新:回顾这段代码，这不是最佳解决方案。

OOP 让这变得更快:

class Vector:
  def __init__(self, x, y, z):
    self.x = x
    self.y = y
    self.z = z

  def __add__(self, other):
    return Vector(self.x + other.x, self.y + other.y, self.z + other.z)

class Color(Vector):
  def __add__(self, other):
    if type(self) == type(other):
      return Color(self.x + other.x, self.y + other.y, self.z + other.z)
    else:
      return Color(self.x + other, self.y + other, self.z + other)

Answer 1

我赞成 Matt Joiner 的回答，但想包含一些额外的观察结果以明确指出，除了其他几个因素外，在预检查条件之间进行选择时，有 4 次很重要(称为 LBYL 或“跳前检查”)并仅处理异常(称为 EAFP 或“请求宽恕比许可更容易”)。

这些时间是:

• 使用 LBYL 进行检查成功的时间
• 使用 LBYL 进行检查时失败的时间
• 当异常没有用 EAFP 抛出时的时间
• 使用 EAFP 抛出异常的时间

其他因素是:

• 检查成功/失败或异常抛出/未抛出案例的典型比率
• 是否存在阻止使用 LBYL 的竞争条件

最后一点是需要首先解决的问题:如果可能出现竞争条件，那么您别无选择，您必须使用异常处理。一个经典的例子是:

if <dir does not exist>:
    <create dir> # May still fail if another process creates the target dir

由于 LBYL 不排除这种情况的异常(exception)情况，它没有提供真正的好处，也不需要做出判断:EAFP 是唯一能够正确处理竞争条件的方法。

但是，如果没有竞争条件，那么任何一种方法都可能是可行的。它们提供了不同的权衡:

• 如果没有引发异常，则 EAFP 接近空闲
• 但是，如果发生异常，则成本相对较高，因为展开堆栈、创建异常并将其与异常处理子句进行比较涉及大量处理
• 相比之下，LBYL 会产生潜在的高固定成本:无论成功或失败，始终都会执行额外检查

然后导致以下决策标准:

• 是否已知这段代码对应用程序的速度至关重要？如果不是，那么不要担心两者中哪个更快，而担心两者中哪个更容易阅读。
• 预检查是否比引发和捕获异常的成本更高？如果是，那么 EAFP 总是更快，应该使用。
• 如果答案是“否”，事情就会变得更有趣。在那种情况下，哪个更快将取决于成功或错误情况是否更常见，以及预检查和异常处理的相对速度。要明确回答这个问题，需要真正的时间测量。

作为一个粗略的经验法则:

• 如果存在潜在的竞争条件，请使用 EAFP
• 如果速度不是很重要，只需使用您认为更易于阅读的那个
• 如果预检费用高，请使用 EAFP
• 如果您希望操作在大多数情况下都能成功*，请使用 EAFP
• 如果您预计操作失败的时间超过一半，请使用 LBYL
• 如有疑问，请测量

*在这种情况下，人们对于他们认为“大部分时间”的内容会有所不同。对我来说，如果我期望操作成功超过一半的时间，我会理所当然地使用 EAFP，直到我有理由怀疑这段代码是一个实际的性能瓶颈。