Статьи > Тестирование статей
AutoCAD .NET API: Исследование возможностей расширенных данных (XData)
Дмитрий Загорулькин:
Описание задачи.
Как известно, XData имеют ограничение по объёму записываемой информации в 16 КБайт. В AutoLISP и ObjectARX API есть даже специальные инструменты для проверки свободного места в XData, тогда как в .NET API, насколько мне известно, таких инструментов нет.
Помимо этого, в XData есть ограничение на длину строки данных - 255 символов. Записать можно и больше, но первый же Audit обрежет эти данные (подробнее - тут).
Добавление 1 (14.12.2018):В чём-то похожее ограничение есть на запись вещественных чисел. API позволяет записывать и извлекать значение Double.NaN, но AUDIT считает эти данные некорректными и при проверке переписывает все эти значения на 0.0 (подробнее - тут).
Само по себе число 16 Кбайт мало о чём говорит - много это или мало? Также, для лучшего понимания, с чем имеем дело, хочется получить ответы на такие вопросы:
1. Сколько может быть зарегистрированных приложений в чертеже?
2. Как влияет длина названия приложения на занимаемый объём?
3. Как влияет длина строки данных на занимаемый объём?
4. Сколько ориентировочно данных различных приложений можно поместить в XData?
5. Сколько ориентировочно данных одного приложения можно поместить в XData?
Условия и используемые инструменты
Платформа: AutoCAD Civil 3D 2014 как AutoCAD (x64)
Объект, в который записываются данные: отрезок, окружность или любой другой простой графический объект. Объект создавался каждый раз непосредственно перед запуском команды записи данных.
Типы записываемых данных: строка, целое и вещественное число.
Используемый код:
Извините, вам запрещён просмотр содержимого спойлеров.
Для проверки записанных данных использовался инструмент ARXDBG: http://adn-cis.org/forum/index.php?topic=7274.0
Результаты исследования.
1. Сколько может быть зарегистрированных приложений в чертеже?
Миллион приложений команда зарегистрировала без ошибок. Правда, при попытке посмотреть данные по базе, AutoCAD завис намертво. При 10000 приложений удалось посмотреть данные в базе:
Вывод: ограничений на количество зарегистрированных приложений нет. Но большое их количество сильно затормаживает работу с чертежом.
2. Как влияет длина названия приложения на занимаемый XData объём?
Название приложения - 8 символов, строка данных – 1 символ. В XData поместилось 2047 записей:
Название приложения – 255 символов, строка данных – 1 символ. В XData поместилось снова 2047 записей:
Вывод: Длина названия приложения не влияет на размер XData.
3. Как влияет длина строки данных на занимаемый XData объём?
Если строка данных имеет длину 1 символ, то в XData помещается 2047 записей:
Если длину строки данных увеличить до 255 – только 31:
А может быть, если записать строки в рамках одного приложения, то получится их больше уместить? Ничего подобного:
То есть, как ни комбинируй, в XData помещается всего 31 строка максимальной длины!
Вывод: чем больше длины записываемых строк, тем больше места занимают данные в XData.
4. Сколько ориентировочно данных различных приложений можно поместить в XData?
Записываются следующие данные: строка длиной 20 символов, вещественное число и целое число. Числа для каждой записи выбираются случайным образом. Это позволит косвенно оценить: будут ли различаться размеры данных в зависимости от различных значений чисел? В результате, было выполнено 273 записи:
При повторных проверках результат не менялся.
Вывод: при небольшом объёме записываемых данных, вместимость XData довольно большая – места хватает для размещения данных 200-300 приложений.
Дополнительный вывод: при различных числовых значениях размер данных не меняется.
5. Сколько ориентировочно данных одного приложения можно поместить в XData?
С теми же данными, что и в предыдущем тесте, циклов записи получилось больше - 287:
Вывод: при записи данных в одно приложение, данных помещается больше, чем если эти данные распределять по разным приложениям. Но эту разницу нельзя назвать существенной.
Общий вывод
XData действительно имеют ощутимый лимит по объёму записываемых данных. Особенно, если записываемые данные содержат строки большой длины. Если же записывать небольшой объём данных, то места может хватить на пару сотен записей.
Александр Ривилис:
Отличное исследование!
Александр Ривилис:
--- Цитата: Дмитрий Загорулькин от 02-12-2017, 02:20:51 ---В AutoLISP и ObjectARX API есть даже специальные инструменты для проверки свободного места в XData, тогда как в .NET API, насколько мне известно, таких инструментов нет.
--- Конец цитаты ---
Можно при необходимости воспользоваться P/Invoke для acdbXdRoom и acdbXdSize.
Дмитрий Загорулькин:
Спасибо!
--- Цитата: Александр Ривилис от 02-12-2017, 16:39:51 ---Можно при необходимости воспользоваться P/Invoke для acdbXdRoom и acdbXdSize.
--- Конец цитаты ---
Я вот как раз раздумываю: а есть ли такая необходимость? Смысл проверять текущий размер XData - быть уверенным, что данные поместятся. Так ведь, если возникает исключение eXDataSizeExceeded, то уже понятно, что данные не помещаются. Или в чём-то другом есть смысл использования этих методов? Мне пока в голову не пришла ни одна такая ситуация, где они бы понадобились.
Александр Ривилис:
--- Цитата: Дмитрий Загорулькин от 04-12-2017, 12:24:18 ---Так ведь, если возникает исключение eXDataSizeExceeded, то уже понятно, что данные не помещаются.
--- Конец цитаты ---
Обработка исключений в .NET - это достаточно ресурсоёмкая операция, требующая еще и временных затрат. Впрочем не уверен, что использование P/Invoke для acdbXdRoom и acdbXdSize даст прирост скорости.
Навигация
Перейти к полной версии