Советы по масштабированию CEDET

Я использую CEDET (последние CVS) с несколькими умеренно большими проектами (несколько сотен kLOCs каждый, в основном C, но некоторые С++), и иногда испытывают длительные паузы, в которых система полностью не отвечает на секунды. Реже он полностью выходит из-под контроля, и я должен затормозить C-g и попытаться переместить курсор или переключиться на другой буфер, чтобы получить контроль.

Я использую GNU Global для создания тегов для проектов, с которыми я работаю, но это все же иногда медленное, особенно для semantic-symref-symbol, и некоторые переходы, которые, похоже, требуют разбора большого количества заголовков и исходных файлов. В некоторых случаях ошибки semantic-ia-fast-jump с сообщением semantic-ia--fast-jump-helper: Tag SomeFunction has no buffer information, хотя gtags-find-tag находит его немедленно (в том же проекте), хотя, возможно, на устаревшем месте; это может быть временная ошибка, обычно semantic-ia-fast-jump является надежной.

Я был бы признателен за любые предложения о том, как

Дроссель CEDET без потери семантического анализа.
Узнайте, что привело CEDET к выходу из-под контроля, поэтому я могу исправить свои определения проекта или написать отчет об ошибке.
Определите, почему не выполняется семантический анализ.
Получите семантику для кэширования дополнительной информации, чтобы сделать ее более отзывчивой, у меня много памяти, которую я бы хотел использовать.
Управление GNU Global (создание и сохранение текущих) для нескольких проектов в разных местах, включая системные каталоги.
Управление зависимостями между проектами, которые я настроил с помощью ede-cpp-root-project.
Управляйте проектами с несколькими конфигурациями сборки, каждый со своим собственным "config.h" и каталогом сборки.

В статье есть несколько советов http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html, я ищу что-либо за пределами этой статьи.

Ответ 1

Инструменты CEDET, которые вы используете, ограничены способностью Emacs отслеживать каждый символ во всем проекте. Хорошей отправной точкой для дросселирования того, что CEDET/Semantic делает через semanticdb-find-default-throttle. Если вы знаете, как организован ваш проект, вы можете отключить некоторые виды поиска, чтобы ускорить процесс.

CEDET проанализирует множество файлов, которые, по вашему мнению, вам понадобятся, которые также заполнят память. В этом случае вы можете настроить semantic-idle-scheduler-max-buffer-size, чтобы отключить синтаксический анализ больших файлов, semantic-idle-work-parse-neighboring-files-flag, чтобы отключить разбор случайного соседнего материала и `semantic-idle-work-update-headers-flag ', чтобы отключить заголовки синтаксического анализа. Обратите внимание, что последние 2 по умолчанию равны нулю, но включены некоторыми функциями автоматической настройки.

CEDET/Semantic будет кэшировать много данных в памяти и создает сортированные таблицы поиска для повышения производительности. Если вы обнаружите, что редактируете файлы заголовков много, эти изменения заставляют кэши устаревать и заставляют их перестраивать. Если вы выходите и перезапускаете Emacs много, то это заставляет Semantic перезагружать большие таблицы базы данных.

Другая возможность - установить semanticdb-persistent-path для перечисления только тех каталогов, о которых вы очень заботитесь. Это сократит сохраненные данные, которые не будут перезагружаться. Если это необходимо, оно будет перерисовываться по мере необходимости, но это поможет сохранить общие данные.

Вы также можете использовать semantic--before-fetch-tags-hook для функции, которая возвращает nil в различных условиях. Найдите файлы, которые занимают много времени для разбора из-за размера, латентности сети или чего-то еще, и настройте их, чтобы никогда не разбираться. Это тоже сэкономит некоторое время.

Использование GNU Global - хороший способ ускорить процесс. Использование его с семантическим symref приведет к тому, что файлы, на которые он находит попадания, будут анализироваться для предоставления требуемых данных для вывода. Это не так много.

Для найденной выше ошибки, если вы можете определить способ ее воспроизведения, поделитесь ею в списке рассылки cedet-devel, чтобы она могла быть исправлена. Этот тип ошибки проявился раньше, обычно, когда тэг GNU Global не удается преобразовать в буферный тег.

Для отладки CEDET, выходящего из-под контроля, используйте semantic-debug-idle-function и semantic-debug-idle-work-function, чтобы сузить все. См. Выше о некоторой конфигурации там.

Вы можете использовать cedet-gnu-global-create/update-database для обновления базы данных или добавить ее к крюку. Я не думаю, что это дошло до документа.

Управление проектами сложно. Большинство встроенных проектов хороши для мелочей. Особенно крупные проекты с пользовательскими системами сборки обычно требуют специального типа проекта EDE. Создание новых проектов не так уж плохо. Если вы посмотрите в ede-linux или ede-emacs, вы сможете поймать основы. В вашем пользовательском проекте вы можете завершить все связанные проекты и переопределить такие функции, как макросы, включить каталоги и команды компиляции. Мне также пришлось написать собственный проект для моей работы. Это было очень похоже на ede-linux с уникальным материалом, где я работаю.