我正在使用调用下载文件的遗留代码库。最好的办法是使它异步，但这不是目前的选择。
另一个选项是优化后端来修复超时。一些现有的调查显示，有8db的调用来做一件事。这已更改为1db调用。性能有所提高，但仍处于边缘。现在，我想把重点放在另外两个问题上。
-
后端使用ORM从prostgres加载到python对象中。该对象包含~30个属性。构造一个包含这30个值的对象的成本与构造6个值(返回给用户的值)的成本相比有多大?
-
有3个for循环(不是嵌套的)，用于格式化，转换和转换对象从一个到另一个。对于50,000个对象，这意味着某些指令要运行150,000次。
现在基于1 &应该优先修复2还是修复1 ?不幸的是，代码的设置方式，我不能在本地运行它来做任何基准测试。唯一的方法就是修改代码，通过PR和部署到登台。所以我想在部署之前看看该关注哪一个。
我个人认为3个for循环应该修改为1。(如果可能的话)与ORM优化。任何想法吗?
我认为你应该专注于1。如果你的循环不是嵌套的，你不会在循环中做任何资源密集型的事情，你应该很好。请记住，如果列表中有1000个项目和两个嵌套循环，则有1M次迭代(1000²)。15万次迭代不算太坏。
另一方面，有时使用ORM会导致SQL查询非常无效。你可以在你的数据库服务器上记录查询，然后想想你能不能写得更好。 ORM的一个典型问题是(当然取决于实现)它使用像 这样的查询SELECT foo FROM bar WHERE id IN (1,2,3,4,5....48500).
你可以很容易地优化代码的子查询，如
SELECT foo FROM bar WHERE id IN (SELECT bar_id FROM othertable)
我喜欢Postgresql的慢速查询日志功能，看看哪些查询需要优化。