Переводчикам на заметку: ускорение работы ABBYY Lingvo и других инструментов

    Электронный словарь сегодня стал одним из основных инструментов переводчика, наряду с браузером, оцифрованными справочниками и базами соответствий (последнее важно в основном лишь для переводчиков нехудожественных текстов).

    Среди электронных словарей ABBYY Lingvo отличается одной ключевой особенностью: полнотекстовым поиском с индексацией. Что-то похожее можно реализовать при помощи индексов в Adobe Acrobat, но удобство интерфейсов именно в словарной области не подлежит сравнению.

    ABBYY Lingvo давно уже превратился из обычного словаря в универсальный агрегатор источников. Вдобавок к титанической работе фирмы-создателя, энтузиастами оцифрованы в формат Lingvo сотни пособий, в том числе и основные двуязычные словари, и многотомные толковые словари серий Cambridge, Collins, Longman, Merriam-Webster, Oxford, и энциклопедические словари вроде Британики. Созданы локальные копии сетевых гигантов (Википедий, Викисловарей, Urban Dictionary и так далее). И при обычном использовании это предоставляло бы исключительные возможности. Но при полнотекстовом поиске всё это богатство превращается ещё и в языковые корпусы и базы соответствий. Значение такого поиска при переводах сложных терминов, устойчивых словосочетаний, фразеологизмов трудно переоценить.

    С каждым выпуском ABBYY расширяет допустимые границы компилируемых словарей и поисковых индексов. Уже сейчас можно скомпилировать словарь размером почти в 2 гигабайта исходного текста. Однако при подключении большого количества словарей индекс разрастается. И сами словари на диске, и поисковый пользовательский индекс также могут достигать гигабайтных размеров. При этом полнотекстовый поиск замедляется, на него начинает влиять скорость работы винчестеров. Эпоха развития SSD может помочь в решении этой проблемы, но пока эти механизмы ещё не используются повсеместно из-за большей цены и меньшей износоустойчивости. К счастью, есть способ, по приросту скорости выигрывающий даже у SSD.

    Можно заставить программу переместить сами словари и поисковые индексы с диска в память. Вернее, мы сами их туда переместим, а программа будет продолжать работать с ними так, будто они всё ещё находятся на винчестере. Поможет нам в этом старое проверенное средство — RAM-диск.

    Существует много программ, создающих подобие диска в памяти. Особое внимание нужно обратить на те, которые позволяют использовать память, недоступную для других нужд.

    В современных 32-разрядных не-серверных Windows есть две основные границы использования памяти: программное ограничение до четырёх гигабайт, которые урезаются до трёх особенностями выделения памяти для устройств. По этим причинам сколько бы памяти вы ни поставили, основные пользовательские Windows не увидят больше 3-х гигабайт плюс/минус ещё чуть-чуть.

    Однако для указанных ограничений есть свои обходные пути: PAE и memory remapping (memory hole, PCI hole). Поэтому, если у вас не 64-разрядная или не серверная система и при этом трёх гигабайт памяти не хватает для размещения там RAM-диска со всем нужным, придётся включать все эти штуки и наращивать память. Биос лучше проверить самостоятельно: например, в этой полезной статье определённым устройствам отказывают в поддержке описанных обходных путей, однако я в биосе своей старенькой обречённой материнской платы таки нашёл опцию «memory hole», после включения которой всё заработало как нужно.

    Перед всеми описываемыми манипуляциями полезно заархивировать важные данные и создать актуальный образ системы для восстановления, если что-то пойдёт не так.

    На сегодняшний день есть две хорошо известные программы, позволяющие использовать всю невидимую для системы память: Primo Ramdisk (VSuite Ramdisk II) и SuperSpeed RamDisk Plus. Если же кто планирует обойтись тремя гигабайтами, можно обратить внимание и на очень быстрый (а по некоторым данным — см. здесь и здесь — самый быстрый) RAMDisk Enterprise. Все эти программы позволяют сбрасывать содержимое RAM-дисков в образы на винчестер перед выключением компьютера или перезагрузкой и восстанавливать образы в память на самой ранней стадии загрузки системы. Хотя это и будет замедлять саму загрузку, будущий выигрыш стоит даже минутной задержки при запуске.

    Большинство материнских плат для десктопов и ноутбуков последних 6-7 лет позволяют устанавливать до 8 гигабайт памяти. Сейчас это уже довольно недорогое удовольствие, и данного размера должно хватить даже для самого богатого набора словарей в Lingvo. Однако в крайних случаях можно обойтись и меньшим размером.

    Что же можно переместить в Lingvo на RAM-диск?

    1. Самое простое — это словари, как пользовательские, так и системные. Пользовательские словари переводчик подключает сам, находится они могут в любом месте. Системные словари на Windows XP находятся в папке c:\Documents and Settings\All Users\Application Data\ABBYY\Lingvo\номер_версии\Dic\System.

    Обе группы словарей можно оставить на их прежнем месте для резерва, а программе указать на папки-копии при помощи файлов словарной конфигурации. Для пользовательских словарей это файл %USERPROFILE%\Local Settings\Application Data\ABBYY\Lingvo\номер_версии\Dic\dictconf.ini, для системных — c:\Documents and Settings\All Users\Application Data\ABBYY\Lingvo\номер_версии\Dic\dictconf.ini. В обоих файлах нужно при помощи автозамены подменить старые адреса на новые, перед этим не забыв сохранить резервные копии обоих ini-файлов. Если же этот способ покажется неудобным, можно прибегнуть к описанному далее.

    Естественно, все предложенные в этом и следующих пунктах манипуляции нужно делать после закрытия программы и выгрузки её из памяти (Lingvo может долго завершать работу, проверять лучше по программам, отображающим активность процессов).

    2. Можно переместить папку с самой программой и бинарными библиотеками (c:\Program Files\ABBYY Lingvo номер_версии). Возможно, впечатляющего прироста скорости это не даст, но что-то можно выиграть. Тем более что в этой папке размещаются также многочисленные файлы .amd и .amm, отвечающие за морфологию. Если программа сама не загружает их в память полностью, а многократно подгружает с диска при необходимости, тогда перемещение имеет смысл.

    3. И наконец — словарные индексы. К системным словарям это будет папка c:\Documents and Settings\All Users\Application Data\ABBYY\Lingvo\номер_версии\Index, к пользовательским — %USERPROFILE%\Local Settings\Application Data\ABBYY\Lingvo\номер_версии\NonAbbyyIndex (хотя можно перенести и всю родительскую папку; для системных словарей лучше этого не делать, потому что вместе с индексом в родительской папке находятся и звуки, которые весят много, а нужны редко).

    Здесь следует оговорить ещё одну трудность. Если перемещение словарей можно подкрепить редактированием файлов конфигурации, то перемещение индексов и самой программы вещь более заковыристая. Но тут нам поможет одно средство, работающее, к сожалению, только на файловых системах NTFS (к счастью, сам RAM-диск может быть и в системе FAT-32: она быстрее, а надёжность и отказоустойчивость при сбоях нам тут не так важна). Это средство — точки соединения NTFS. Primo Ramdisk (VSuite Ramdisk II) имеет встроенную утилиту для их создания, но можно воспользоваться и утилитой Junction (а начиная с Windows Vista можно просто применять команду mklink). Алгоритм очень прост: копируем папку на RAM-диск (переназвать её там можно как угодно), для резерва переименовываем оригинальную папку во что-то вроде «оригинальное_название_bak» и создаём к копии точку соединения в родительской папке оригинала с оригинальным названием. Всё работает прозрачно, программа не будет делать никакого различия между прежней работой с оригиналами и новой переадресацией к копиям.

    Напоследок следует заметить, что при добавлении словарей и обновлении индексов нужно синхронизировать содержимое папок в памяти и резервных оригиналов на дисках — на случай, если при сбое системы программа, управляющая RAM-дисками, не успеет сбросить содержимое в образы или образы будут повреждены. Тогда всегда можно будет восстановится с резервных копий.

    При полноценном перемещении ускоряется запуск и закрытие программы, синхронизация списка слов с полем ввода слова, переключение языков, поиск слова и открытие карточек, но особенно разительно — во много раз — ускоряется полнотекстовый поиск и поиск по маске в заголовках.

    ***

    Работу с RAM-диском стоит также взять на вооружение тем, кто оцифровывает словари. Иногда приходится работать с текстовыми файлами гигабайтных размеров. И хотя есть текстовые редакторы для работы с такими громадными исходниками, поиск, ручное редактирование и операции автозамены (всё время используемые при создании разметки языка DSL) происходят при этом очень медленно. Если же поместить исходник в память, и редакторская работа с ним ускорится, и компиляция, возможно, также пойдёт быстрее.

    Все эти навыки можно применить и к другим программам. Поскольку браузером переводчики пользуются сейчас столь же часто, как и словарями, стоить подумать о перемещении в память браузерных профилей с их базами данных, а также браузерных кэшей. К счастью, статей об этом много, даже на одном только Хабре.
    Поделиться публикацией
    Комментарии 13
      0
      Вопрос, а ssd не дает достаточного повышения производительности, что бы не париться с рамдиском? Линейная скорость высокая, а рандомная до 50к микро операций в секунду, что опять во много раз быстрее чем диск. Так же вопрос, а почему не работает кеш файловой системы?
        +1
        Я хотел сказать, если сделать 8Gb памяти, то в течении некоторого времени все окажется в кеше, без использования рам диска.
          0
          Можно рискнуть отключить файл подкачки, если вы об этом. Или перенести и его в невидимую память.
            +1
            А 32-х битная винда умеет пользоваться для кеша диска памятью за границей первых 4-х гигов?
              0
              То есть может ли она принять рамдиск в невидимой памяти за обычную память и переносить его в своп? А ведь точно, это вряд ли.
            0
            Я сам не проверял, но искал в сети ответы на «RAM-disk vs SSD». На IT и оверклокерских сайтах говорят об очень существенной разнице в скорости. К тому же установка XP на SSD связана с целым рядом оговорок, всё равно придётся переносить что-то в RAM. Так что, думаю, оба выхода — дело личного желания решать одни или другие проблемы.
              +1
              Кстати, цена сейчас 9 килорублей за 256Gb, что скажу очень немного, еще полтора года назад было за 20 килорублей, и скорости были ниже.

              Да скорость конечно во много раз быстрее. Я почему про кеш заговорил, потому что в свое время когда было мало памяти, около гигабайта, полтора что-ли, я пытался выделить 256-512 мегов для основных данных на XP, что бы они всегда быстро грузились и потом очень сильно погряз в стабильности работы (проблемы с питанием, возможные зависания) и двухсторонней синхронизации при включении-выключении. Мое мнение, что оптимальнее SSD ну по крайней мере на текущий момент. Однако в вашем случае все немного проще, так как синхронизация односторонняя и если что, то данные не подпортятся. В общем целом тоже хороший способ тогда получается, если лень купить SSD, тем более внушительное количество памяти будет стоить 3-4 килорублей, при условии, что не нужно менять мать.
                0
                Да сейчас на рынок выкинули совсем дешёвые модели от Silicon Power. 64 гигабайта за 50 долларов с копейками. Скоро можно будет будет пользоваться ими почти как расходным материалом, если ситуация с износоустойчивостью ничего не измениться.

                Да, системные переносы — вещь более хрупкая. Но в данном случае и правда достаточно всегда иметь под рукой актуальные резервные копии папок (при добавлении словарей и обновлении индексов не забывать копировать их из памяти в архивные папки не диске).
            +2
            Показала статью разработчикам Lingvo. Просили передать, что в следующесий версии поработают над ускорением всей Lingvo в целом.
              0
              Спасибо большое. Было бы здорово, если бы добавили опцию переноса всех индексов и словарей в память, как это бывает при работе с некоторыми базами данных, если я не ошибаюсь. Хотя система может всё это в обратно в своп перекинуть… Но тут я не специалист, к сожалению, не знаю всех тонкостей.

              Но прирост скорости полнотекстового поиска очень ощутимый. Раньше при большом количестве словарей такой поиск мог несколько секунд продолжаться, теперь всё мгновенно работает.
                +1
                Ага, передам.
              +1
              По поводу «точек соединения NTFS» (а попросту — ссылок на каталоги): начиная с висты (NT 6.0) это средство доступно из коробки по команде MKLINK.
                0
                Спасибо большое. Я внесу в текст.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое