我正在使用pycontractions中的一个函数来尝试将文本扩展为语法准确的形式。它的工作,但其令人难以置信的缓慢,我不能不怀疑,如果我做了一些不必要的,是造成性能滞后。作为参考,输出大约需要一分钟。你知道吗
from pycontractions import Contractions
def cont_expand(a):
cont = Contractions(api_key="glove-twitter-100")
expText = cont.expand_texts(a, precise=False)
return expText
mystr = ["I'd like to have lunch today"]
x = list(cont_expand(mystr))
我以前不知道
pycontractions
库,也不曾使用过它,但通过快速查看,我有一些想法。你知道吗首先,关于您的用法:
Contractions
对象需要从磁盘加载一大组预先存在的单词向量来进行一些分析。它还需要实例化另一个库language-check
,它显然包装在一个基于Java的语法检查工具上。你知道吗看一下source code,我发现它实际上是在
expand_texts()
期间第一次需要初始化时,而不是在提供api_key='glove-twitter-100'
的对象初始化期间,以一种惰性的方式进行初始化。)在像探测值这样的小文本中,可能是运行时的最大贡献者。因此,在刚刚初始化的
Contractions
对象上的一个expand_texts()
并不能准确指示该对象在后续类似文本上的性能。因此,假设每个Python调用的实际使用都不止一个文本,您应该:Contractions
对象例如:
除此之外,您的用法非常简单,我看不到您可以通过调用该库来加快速度的其他方法。你知道吗
然而,稍微研究一下
pycontractions
的工作原理,我并不惊讶它的速度相当慢,尤其是在大文本上。它所做的事情,在内部,通常是相当缓慢的进程,而且它还以没有经过严格优化的方式来做这些事情——这可能是非常好的,因为代码简单,尤其是在短文本上,除非/直到需要更高的性能。你知道吗例如,它描述了使用“三通”方法。你知道吗
第一步涉及许多基于模式的替换,对于这些替换,源代码有数百个独立的正则表达式。为了执行第一步,每个文本都需要在一个循环中通过这数百个表达式进行正则表达式匹配。(有一些方法可以优化此过程以使用较少的过程。)
对于具有多个可能的扩展的压缩(其中包括测试字符串中的“I'd”),它将执行每个扩展并检查其语法。幸运的是,这只涉及一些扩展,但是语法检查也不是最便宜的操作。
对于每一次交替展开,它都会计算一个基于词向量的语义差异度量,称为“词移动器距离”(word Mover's Distance),这本身可能非常昂贵,尤其是在较长的文本上。(它从零开始为每个候选者做这个计算——即使除了几个单词,每个候选者的开头都是一样的——即使找到了至少一个语法选项,它也会继续为没有机会被选中的非语法候选者做这个计算。)
在每个步骤中,它都将临时结果保留为原始字符串,因此
pycontractions
代码或各个支持库的代码都会重复执行相同的标记化步骤。你知道吗因此:如果您是批量执行此操作,并且对底层库的修复也在范围内,那么可能有很大的空间进行微优化。你知道吗
但我认为,对于许多临时使用,只要确保不重复支付每个操作的
Contractions
初始化加载成本就足够了。你知道吗相关问题 更多 >
编程相关推荐