Раньше я не знал или не работал с библиотекой pycontractions, но при быстром взгляде у меня есть несколько идей.
Прежде всего, относительно вашего использования:
Объект Contractions должен загрузить с диска большой набор уже существующих векторов слов, чтобы выполнить его анализ. Также необходимо создать экземпляр другой библиотеки language-check, которая, очевидно, использует утилиту проверки грамматики на основе Java.
Глядя на исходный код , я вижу, что на самом деле эти инициализации выполняются ленивым образом, когда они сначала нужны во время expand_texts(), а не во время инициализации объекта, когда была предоставлена api_key='glove-twitter-100'.)
В небольшом тексте, таком как значение вашего пробы, может стать самым крупным источником времени выполнения. Таким образом, один expand_texts() на только что инициализированном объекте Contractions не будет точным показателем эффективности этого объекта для следующих похожих текстов. Таким образом, предполагая, что ваше реальное использование будет более чем для одного текста на один вызов Python, вы должны:
- изменить свой код, чтобы повторно использовать один, один раз созданный
Contractions объект - заставляет этот объект полностью загружать свои подкомпоненты, принимая удар вперед, прежде чем сравнивать его с реальной работой
Например:
from pycontractions import Contractions
PYCNTRCTNS = Contractions(api_key="glove-twitter-100")
# dummy call to force vector/grammar loading
PYCNTRCTNS.expand_texts([]) # expect this to take a while
def cont_expand(a):
expText = PYCNTRCTNS.expand_texts(a, precise=False)
return expText
mystr = ["I'd like to have lunch today"]
x = list(cont_expand(mystr)) # care about how long this takes
Кроме этоговаше использование довольно простое, и я не вижу других вещей, которые вы можете сделать, вызывая эту библиотеку по-другому, чтобы ускорить процесс.
Однако, немного рассмотрев, как работает pycontractions, я не удивлюсь, что он довольно медленный, особенно для больших текстов. То, что он делает, внутренне, часто является довольно медленным процессом, и он также делает это способами, которые не сильно оптимизированы - что может быть прекрасно, для простоты кода, и особенно для коротких текстов, если только не будет достигнута более высокая производительностьнеобходим.
Например, он описывает использование трехпроходного подхода.
Первый этап включает в себя ряд замен на основе шаблонов, для которых исходный код имеет сотни отдельных регулярных выражений. Для выполнения этого 1-го шага каждый текст должен быть согласован с регулярными выражениями по этим сотням выражений в цикле. (Есть способы оптимизировать это, чтобы использовать меньше проходов.)
Для сокращений, которые имеют несколько возможных расширений - включая «Я» в вашей тестовой строке - он выполняет каждое расширение& проверяет свою грамматику. К счастью, это включает только несколько расширений, но проверка грамматики также не самая дешевая из операций.
Для каждого альтернативного расширения он вычисляет основанную на слове-векторе меру семантической разности, называемую «Расстояние до слова», которая сама по себе может быть довольно дорогой, особенно на более длинныхтексты. (Он делает это с нуля для каждого альтернативного варианта - хотя, за исключением пары слов, каждый альтернативный вариант начинается одинаково - и даже после того, как найден хотя бы один грамматический вариант, он продолжает выполнять этот расчет для неграмматических кандидатов, у которых нет шансов бытьselected.)
И на каждом шаге промежуточные результаты хранятся в виде необработанных строк, поэтому либо код pycontractions, либо код отдельных вспомогательных библиотек многократно выполняют одни и те же шаги токенизации.
Итак: если вы делали это массово, и исправления для базовой библиотеки были доступны, вероятно, есть много места для микрооптимизации.
Но я думаю, что для многих случайных случаев достаточно быть уверенным, что вы не платите многократно стоимость инициализации-загрузки Contractions для каждой операции.