擅长:python、mysql、java
<p>好吧,在反复摆弄计时器之后,我终于明白了。匹配时有几个功能:exactMatches、matchGapper和arbSubset。当我将计数器放入全局变量并测量操作时(以执行的<em>我的代码</em>的行来测量,对于大输入<strong>约为2-10K(约为10个标记))</p>
<p>的确,返回子集列表的arbSubset一开始似乎是一个看似合理的瓶颈。但是如果你仔细观察,我们1)处理少量的标记(顺序为10-50),更重要的是,2)我们在递归matchGapper时只调用arbSubset,这最多只发生10次,因为tagsList只能在10左右(顺序为10-50,如上所述)。当我检查生成仲裁子集所需的时间时,它的顺序是2e-5。因此,生成任意大小的子集所花费的总时间仅为2e-4。换句话说,不是web应用程序中5-30秒等待时间的来源</p>
<p>因此,撇开这一点不谈,我知道arbSubset只被调用了10次,而且调用速度很快,而且知道在我的代码</em>中最多只进行了10K次计算,我开始清楚地意识到我必须使用一些开箱即用的函数,我不知道像set()或.issubset()或者类似的东西,需要大量的时间来计算,并且执行了很多次。在更多的地方添加一些计数器,很明显exactMatch()占发生的所有计算的95-99%左右(如果我们必须检查各种大小的子集的所有组合以获得exactMatch,这是意料之中的)</p>
<p>因此,在这一点上,问题归结为这样一个事实:exactMatch在实现时大约需要0.02秒(经验上),并且被称为数千次。因此,我们可以尝试通过几个数量级使其更快(这已经是非常优化的),或者采取另一种不涉及使用子集查找匹配的方法。我的一个朋友建议创建一个包含所有标记组合(so2^len(tagsList)键)的dict,并将它们设置为具有该精确组合的已注册配置文件列表。这样,查询就是遍历一个(巨大的)dict,这可以很快完成。欢迎提出任何其他建议</p>