Возможно, это не ответ, но вот некоторые комментарии, которые могут помочь.
Как указано в названии, RutaRuleElementMatch хранит совпадения элементов правил, которые требуются с одним RuleMatch, чтобы идентифицировать информацию для действий. Эта информация может быть забыта после RuleMatch, но иногда ее необходимо сохранить. В основном, он сохраняется, если движок анализа настроен для отладки (параметры debug
и debugWithMacthes
). Затем все совпадения правил и совпадения элементов правила запоминаются для создания аннотаций отладки позже. Если есть много совпадений, это может занять много памяти в текущей реализации.
Конфигурация отладки также используется в Java API, например, в Ruta.select() или Ruta.matches(). В меньшем количестве совпадения также запоминаются для основных правил операторов блоков.
Таким образом, если отладка активирована, ее необходимо деактивировать, чтобы уменьшить использование памяти.
400KB текста довольно много, я думаю. Ruta приносит довольно некоторые издержки, что требуется, но также может быть улучшено/уменьшено. Прямо сейчас, до тех пор, пока реализация не будет улучшена, есть несколько лучших практик для обработки большого документа в руте, т. Е. Уменьшения использования памяти.
В вашем случае использования я бы переключился на другую сеялку, которая создает только нужные вам аннотации, и только там, где они вам нужны, например, вам нужно пространство и перерыв? Тогда я бы реорганизовал правила. Правило примера, указанное в комментариях, крайне неэффективно и создает много RuleElementMatches. Я скорее рекомендую использовать словарь, где это возможно, например. с TRIE
. Вы также можете улучшить такое правило, ограничив условие соответствия. В вашем примере это может быть W
или результат поиска в словаре.
Если профилирование показывает, что RutaRuleElementMatch использует большую часть памяти, это может быть вызвано конфигурацией отладки или неэффективными правилами.
Если профилирование показывает, что RutaBasic использует большую часть памяти, то это обусловлено размером документа и, следовательно, количеством аннотаций. Уменьшение количества аннотаций помогает, так как меньше информации о покрытии необходимо хранить во внутренних списках/массивах. UNMARK
и UNMARKALL
помогают также, но не дольше, как ожидается, по крайней мере, в моих случаях использования. Существует также параметр lowMemoryProfile
, который уменьшает использование памяти RutaBasic, а также производительность во время выполнения, как вы упомянули. Тем не менее, я полагаю, что ваши правила могут быть оптимизированы очень сильно, так что параметр снова будет вариантом.
Надеюсь, это поможет.
ОТКАЗ: Я разработчик UIMA Ruta
Какая часть API Java вы используете? –
Что вы подразумеваете под REGEXP-структурами? Состояние REGEXP или простые правила регулярного выражения? Какими правилами являются действия UNAMRKALL? Что вы подразумеваете под конечной точкой? –
Как я должен понимать вопрос для JavaAPI? Мы создаем AnalysisEngine, как описано в документации для этого API, добавляя все необходимые типы систем и нажимаем текст для анализа с этим движком с помощью метода process. REGEX-Структуры находятся в условной части нашего составленного правила, как показано в следующем примере: ** (ЛЮБОЙ {REGEXP ("(H | h) ello")} ЛЮБОЙ {REGEXP ("(Mr | Mrs .) ")}) {NOT (IS (Приветствия)) -> MARK (Приветствия)} ** –