Как уменьшить размер файла 1cv7.md

Во-первых, надо четко понимать, что контейнерный файл - своеобразная база данных. А базы данных имеют обыкновение хранить в себе пустые места. Например, в dbf удаленные записи не удаляются, а освобождаются для последующих записей. md - не dbf, но и в нем при определенных действиях возникают "дырки".

Сохранение файла 1cv7.md может происходить двума способами. Простое сохранение без лишних вопросов происходит, если изменения коснулись только в модулей, а так же печатных и экранных форм. Сохранение с анализом изменений и возможной реорганизацией БД происходит в тех случаях, когда она предполагает изменение структуры данных. Простейший способ этого добиться, не изменяя конфигурацию - добавить и тут же удалить новую константу или реквизит любого справочника/документа. Можно так же зайти в свойства любого реквизита или объекта, и в комментарии добавить и тут же удалить пробел (я именно так и делаю).

Так вот: только после сохранения с анализом изменений мы можем получить 1cv7.md минимального размера для текущей функциональности.

Иногда мне кажется, что я не всегда внятно излагаю :), поэтому вот тут можно посмотреть описание того же эффекта другими людьми.

Вместо сохранения измененной конфигурации - можно еще перепаковать конфигурацию gcomp'ом

Во-вторых, как уже было сказано чуть выше, присутствие или отсутствие файлов container.profile никак не влияет на функциональность конфигурации. Соответственно, мы можем удалить все такие файлы с помощью плагина к FAR'у, потом загрузить получившуюся конфигурацию как измененную, сохранить, и получить выигрыш по 512 байт на каждый такой файл.

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

Если вам лень перебирать ручками все папки в поисках потоков Container.Profile - воспользуйтесь утилитой gcomp, и с ее помощью перепакуйте конфигурацию с ключом --no-profiles.

В-третьих, после вдумчивого рассмотрения всех каталогов, я обнаружил одну забавную особенность каталога Journal. В нем оказались каталоги с идентификаторами, для которых не существует форм журналов. Однако, эти идентификаторы порой совпадали с идентификаторами самих журналов. Вероятно, еще в версии 7.0 (я знаком с ней весьма поверхностно, поэтому не могу утверждать наверняка), журналы документов могли иметь только одну форму списка. Очевидно, что эта форма имела тот же идентификатор, что и сам журнал. Когда же в версии 7.5 появилась возможность заводить несколько форм для одного журнала, идентификаторы форм, очевидно, пришлось поменять. Однако при преобразовании конфигурации из старого формата "старые" формы, видимо, забыли удалить. Эти формы можно легко опознать по идентификатору - они все меньше 900. В качестве дополнительного подтверждения того, что эти каталоги абсолютно излишни на текущий момент, могу указать на то, что в соответствующем Container.Contents из каталога Journal нет ни одного упоминания о том, что такие папки должны присутствовать.

В комплексной 2.6 таких "забытых" форм 13 штук. Если учесть, что каждая состоит как минимум из пяти файлов и одного каталога, то нетрудно посчитать, что их удаление принесет нам 6 * 13 * 512 = килобайт 40 как минимум. А за счет того, что экранные формы меньше трех кластеров почти никогда не занимают, реальный выигрыш наверняка окажется вдвое значительнее.

И здесь поможет перепаковка конфигурации gcomp'ом. И даже никаких опций не нужно.

Более детальное исследование экранных форм показало, что для каждого объекта на форме хранится название того слоя, которому этот элемент принадлежит. По умолчанию, название единственного слоя - "Основной". Если слой один, а объектов на форме два десятка, то постым переименованием слоя в "О", можно добиться экономии 7 * 20 = 140 байт. И если повезет, форма станет занимать на один 512-ти байтный блок меньше. Если Вам кажется, что это мелочь - вспомните, сколько экранных форм в конфигурации.

Здесь готового решения нету. Однако теоретически можно написать скриптик, который переколбасит разобранную gcomp'ом конфигурацию, после чего собрать ее обратно.

Вспомним о пустых таблицах. Они занимают один кластер, то есть, 512 байт. Просто удивительно, насколько их много, особенно в формах журналов, обработках и формах списков справочников (то есть там, где они абсолютно не нужны).

И здесь у gcomp'а нашлась опция. --no-empty-mxl называется.

Что касается справочников. У справочника, как мы помним, есть аж три формы: списка, группы и элемента. Так вот, если в справочнике один уровень, то форма группы, очевидно, не нужна. Если справочник редактируется только в списке, то не нужна еще и форма элемента. И если первую ситуацию 1С отслеживает и предлагает удалить неиспользуемую форму группы, то ненужную форму элемента не только нельзя удалить штатными способами, но она еще и автоматически будет создана при первой попытке в нее войти (что-то MS запахло, не правда ли?). Удалить такую форму можно только хирургически, читай, с помощью плагина DocFile Browser. Главное, не забыть удалить ссылку на удаленный каталог в Subconto\Container.Contents

Данная тонкая хирургия gcomp'у неподвластна.

Еще одно поле для деятельности - картинки. Для gcomp'а создан скрипт (show_pics), который показывает статистику по используемым (и главное - по неиспользуемым) картинкам. А картинки могут быть большими, очень большими, и воистину огромными.

Однако самый эффективный способ уменьшения размера конфигурации - удаление лишнего функционала и оптимизация существующего. Комплексная в этом смысле - непаханное поле. Впрочем, это уже совсем другая история...