我正在运行一些模拟过程太慢，因此我对我的代码进行了剖析，发现超过90％的时间花在将（2D）numpy数组转换为字符串，如：将numpy数组转换为字符串的最有效方法
arr = np.ones(25000).reshape(5000,5)
s = '\n'.join('\t'.join([str(x) for x in row]) for row in arr]
我尝试了很多不同的解决方案（使用地图，将使用astype（STR）的阵列，铸造到一个列表），但大多数只给了边际改善。
最终我放弃了试图将数组转换为字符串，并使用np.save(arr)，这给了一个2000X（！）加速其保存到自身的文件。有没有办法将数组写成具有类似性能的文本文件？
将numpy数组转换为人类可读形式决不会确定模拟的运行时间。事实上，它甚至不应该贡献（显着）。
您应该在不同的级别上解决这个问题。问问自己：你真的需要多长时间将数组写入文件中人可读的表单？它是否需要经常/经常发生，以至于它明显决定了代码的运行时间？只有当一次，当某个结果存在时，它是否足够？
当你采取这种方法时，你可能不需要优化你当前的书写方法。我可能想给一些数字。考虑到你的模拟需要大约一个小时（没有将结果写入磁盘）。我认为那么你同意，如果你的代码花费了10秒的时间将结果写入磁盘，这是可读的。如果这需要10秒，1秒或100秒，那真的没有关系。
如果出于某种原因，您确实需要定期将您的中间结果写入磁盘以供日后处理 - 将频率降至最低，并使用二进制数据格式。
尝试使用np.savetxt（“file”，arr）。请参阅此处的文档 - （http://docs.scipy.org/doc/numpy/reference/generated/numpy.savetxt.html）。
是的，试过了，还是太慢了。 – 2015-02-10 18:39:44
因为OP没有提到他们试过这个，所以我并不完全赞同这里的提议。国际海事组织你永远不会像savetxt一样快（这是针对C中的工作进行手工优化），所以这确实回答了这个问题。也就是说，Jan的答案是最好的 - 不要优化这个位/找出使用二进制数据的方法。 – 2015-02-10 19:10:23
是的，这就是我最终做的 - 每个模拟只需要大约1.5毫秒，然后转换为一个字符串需要大约500毫秒。 – 2015-02-10 18:39:18
那么 - 你的问题解决了吗？如果不是这样：您需要执行多少次这些短模拟？什么是输出文件？对于人类还是机器？这些输出文件有多大？ I/O是一个限制因素吗？ – 2015-02-10 18:40:51
是的，问题解决了。我只是想知道是否有一种方法可以将numpy数组写入字符串，其性能与np.save（fn，arr）相同。 – 2015-02-10 18:42:55