О динамике и параметрике в AutoCAD.
Возможно, кому-то окажется вновинку, возможно, кого-то спровоцирует на содержательный ответ 
В общем, мое личное мнение касательно динамических блоков в AutoCAD и параметрических зависимостях.
Скажу сразу: параметрикой лично я не пользуюсь - просто не надо, но некоторое представление о ней и о "пользе", наносимой этим нововведением, у меня есть. Надеюсь, что есть.
Сначала про динамику, хорошо?
Итак, мы создали уникальный динамический блок - несколько вариантов видимостей, масса зависимостей и теде, и тепе. Начинаем вставлять - опаньки, AutoCAD начинает безбожно тормозить. Мало того, как недавно выяснилось, файл может вообще не сохраниться при некоторых условиях.
Дело в том, что это только для пользователя вхождение динамического блока имеет одно и то же имя независимо от состояния его параметров. А вот для AutoCAD каждое такое вхождение - отдельный анонимный блок (кстати, именно поэтому не корректно работает знаменитый _attout). И, как мне кажется, на каждое вхождение "навешаны" объектные реакторы.
А теперь представьте: допустим, создан динамический блок с 2 состояниями видимости и в каждом пускай по 5 линейных параметров. В таблице блоков - 1 запись, плюс словарные записи, регулирующие поведение 10 параметров. Каждое вхождение - дополнительно 11 записей (не меньше!) Это же все равно, как в каждом вхождении руками создавать новый блок! Рано или поздно AutoCAD "ловит" переполнение по одному из критериев и начинаются танцы с бубнами для нормальной работы с файлом и его сохранения.
Именно поэтому лично я стараюсь динамику использовать "по минимуму" - там, где без нее совсем становится уныло. И очень осторожно, с минимальным набором параметров и видимостей.
Теперь о параметрике... Параметрические зависимости, как мне кажется, вообще зло. Поскольку реализованы через объектные реакторы: т.е. на каждый "завязанный" в параметрические зависимости графический примитив дополнительно вешается отдельный объектный реактор. В свое время я экспериментировал с объектными реакторами и понял, что от них никакой пользы, кроме вреда : опять словарные записи, опять "мусор", опять проблемы с очисткой файла от следов таких шуток... Конечно, Autodesk корректно создал механизм очистки параметрических зависимостей, что не может не радовать.
Но мои личные эксперименты заставляют меня держаться подальше от таких вещей (имею в виду объектные реакторы, и все, что на них реализовывается) и использовать их только в случае крайней необходимости.
Алексей, хотел задать вопрос по динамике. У меня такая ситуация, что на чертеже может быть около 10-20 разных динамических блоков, и у каждого из них 20-100 слоев видимости, по 3-5 лукапов. Естественно вхождений динамических блоков с разными параметрами много. Тормозят только отдельные личности (блоки, которые собраны как-то криво). И вот я медленно подхожу к вопросу. Блоки будут переделываться и количество блоков, слоев видимостей увеличиться.
Когда наступит это "Рано или поздно AutoCAD ловит переполнение по одному из критериев и начинаются танцы с бубнами для нормальной работы с afqkjd и его сохранения"? Как это отследить?
Доброго. Расскажу как я это понимаю (но пока явных опровержений таких измышлений не видел).
Суть в том, что каждый элемент - графический, или неграфический - внутри файла получает свою уникальную метку. Так называемый Handle (хендл, или хэндл).
Можно посмотреть этот Handle для последнего созданного примитива, вбив в ком.строке код
Как только показываемое значение приближается к максимально допустимому, можно готовиться к появлению проблем. Так, например, для AutoCAD 2009 максимальное значение этой метки равно FFFFFFFFFFFFFFFF (исчисляются они в шестнадцатиричной системе).
Еще пара моментов: удаление примитива не освобождает Handle; нередко изменение одного из параметров динамического блока просто создает новый анонимный блок, удаляя вхождение старого. А это далеко не один примитив и, соответственно, далеко не один Handle.
P.S. Прошу прощения за некоторую сумбурность ответа, но просто сейчас читаю курсы, уже слушатели пришли...
Спасибо за ответ. Был занят, поэтому не мог ответить оперативно. Решил поставить пару экспериментов над дин. блоком.
Параметры дин. блока: стол лабораторный - прямоугольник, внутри прорисован каркас; четыре лукапа, при изменения которых меняются параметры блока - в основном длина и слой видимости (их 100 шт.).
Параметры системы: Win7x64, AutoCAD2013x64
Эксперимент 1. Просто вставил блок и увеличивал количество в геометрической прогрессии (множил на два). При 10 тис. вхождение метка имела значение DEC 349355 (HEX 554AB). Зависимость линейная, т.е. переполнение ожидается при кол-ве вхождение 5 х 10^17.
Эксперимент 2. Вставил блок и увеличивал количество в геометрической прогрессии (множил на два), с каждый разом менял один из параметров для всех блоков. До 10 тис. вхождений не дошел, остановился на 5 тис. - метка имела значение DEC 3595393 (HEX 36DC81). Зависимость опять линейная, переполнение ожидается при кол-ве вхождение 2,6 х 10^16.
С 80-ю блоками начались тормоза, когда выделяешь их скопом, пытаешься всем одновременно поменять параметр. При 640 это стало затруднительно (перекура не хватило). При 2500 шт. практически невозможно было поменять всем одновременно.
Особых тормозов при зумировании и панорамировании не заметил, только копирование большого массива блоков и изменения одновременно какого-нибудь параметра.
Вывод, который сделал для себя: возможно эксперименты не охватывают все случаи жизни, но о переполнении метки handles можно особо не беспокоиться.
Но ведь возможности дин.блоков не ограничиваются только параметром видимости. Стоит прилепить пару-тройку линейных параметров и менять их уже менее предсказуемо - станет более весело.
P.S. Для ускорения работы с такими количествами объектов можно временно закрывать панель свойств, а быстрые свойства просто отключить.
P.P.S. Можно немного усложнить эксперимент: вставлять блоки в абсолютно пустой новый файл. Старые вхождения, после внесения изменений, удалять. Но это лирика. А практика показывает, что дойти до переполнения можно - ведь нередко с одним файлом работает несколько человек, и работа длится днями, если не неделями. Что там будет нарисовано / удалено / изменено - неизвестно никому...
У меня в блоке три линейных параметра, завязанные на три лукапа, и один лукап завязанный на эти три лукапа.
P.S. Про скрытие панелей свойств и быстрых свойств знаю. Спасибо.
P.P.S. Попробую свой эксперимент №2 дважды или трижды - после 1 тис. вхождений буду удалять блоки и вставлять заново.
Зацепился за этот вопрос, потому что пытаюсь всю работу отдела (и не только) полностью свести к дин. блокам, и он в данной ситуации важен. Не хочется завалиться в конце
Для бОльшего интереса можно сделать еще пару "финтов": в один файл загнать 1-2 тысячи вхождений разных дин.блоков с разными параметрами, сохранить его и вставить внешней ссылкой в другой. Создать отрезок (во втором файле, естественно), посмотреть его хендл.
Скажу честно - я подобным не занимался, некогда 
Самое интересное начнется, когда будут вноситься изменения в описания динамического блока - например, добавится пара-тройка параметров
А так - вариантов можно придумать много.
Вот уж что-что, а параметрика достала. Несколько раз удавалось отбиться от нее стандартными средствами, но пришел-таки момент, когда на все мои попытки акад пишет "нет зависимостей для удаления" при нагло светящихся желтых квадратах. Перерыв.
http://autolisp.ru/2017/05/15/parametric-clean/