许多Numpy数组而很少Python类

我正在从事一个项目，该项目严重依赖于相当小的2D Numpy数组来表示我们的数据（最坏情况下，小数组约为100 x 4）。这种表示法的问题是，考虑到问题的上下文，它非常麻烦和不清楚，维护起来非常糟糕，而且非常容易出现错误。例如，在这些数组的上下文中，我当前的任务需要添加和删除多行，并分配大量行。我认为面向对象的、基于图形的方法在我这方面使用起来更加清晰，在未来的开发中更加通用。坐下来在纸上设计大部分功能后，可能会有5到6个更大的类，带有内部字典（表示图形的邻接列表），这样就不需要Numpy数组，而且解释起来更清晰

众所周知，就索引速度和大多数其他功能而言，Numpy数组将Python数据结构一扫而光。然而，我也知道Python字典是高度优化的，并且其本身相当有效。我的难题是，重新分配许多Numpy数组并来回复制值是否比几个持久化类的效率更高或更低，这些持久化类无需重新分配即可轻松编辑，但索引时间比Numpy数组慢

值得注意的是，除了

np.where（）

，我没有使用太多的Numpy功能，如果需要，可以使用这些功能。此外，该算法的规模不在于数组的大小，而在于数组的数量；更难的问题将有更多的数组，但不一定是更大的数组

---

谢谢

您是否考虑过性能分析（评测等）？谁说numpy数组比python数据结构更快？取决于你在做什么以及你如何访问数据。“过早的优化是万恶之源”-复杂而困难的代码紧随其后-从简单清晰的方法开始，看看你是否需要优化，然后通过一些Cython或C来分析并抓住可能带来最大好处的点。你不需要得到它“完全启动并运行“，足以看出瓶颈操作是否会成为杀手。如果不经常使用矩阵运算，则可能无法充分利用

numpy

。还要记住还有其他方面；正如您所评论的，拥有更直观的模型将影响进一步的开发和维护时间。我们不能告诉你这对于你的用例来说是否是至关重要的。总有一个折衷的办法。。。当然，您不想过早地进行优化，但您也不想花一周的时间编写代码，因为这样的代码很有可能太慢，无法满足您的需要。与纯python相比，Numpy可能不可读，但您可以将边界上不可读的部分填充到命名和文档化良好的小函数或类中。这可能会很困难，但我会尝试猜测算法的哪些部分会成为瓶颈，并做一个简单的计算，以确定您使用numpy获得的10-100加速系数是否值得注意。