Сравнение производительности коннекторов Speckle
Эта статья немного отличается от моих обычных публикаций. Обычно я подробно разбираю тему, сравниваю подходы, показываю графики и таблицы и обращаю внимание на детали, которые легко упустить. В этот раз я решил представить результаты иначе.
Речь о Speckle, точнее о коннекторах и способах передачи моделей из Revit и Navisworks, а также через IFC. Почему именно эти форматы? Я использую их каждый день и знаю, как они ведут себя в реальных проектах.
Речь о Speckle, точнее о коннекторах и способах передачи моделей из Revit и Navisworks, а также через IFC. Почему именно эти форматы? Я использую их каждый день и знаю, как они ведут себя в реальных проектах.
Ранее в LinkedIn я рассказывал, что планирую большое тестирование Speckle. По мере работы стало понятно, что вся тема не поместится в одну публикацию. Speckle представляет собой целую экосистему, поэтому я начал с коннекторов: именно через них модель попадает в сервис.
Для результатов я выбрал интерактивный виджет. Тестов оказалось много, и каждую комбинацию я повторял трижды. Основная схема выглядела так:
В описании работы указаны 54 экспорта в основной серии и более 200 измерений с учётом дополнительных проверок. Вместо просмотра множества таблиц можно выбрать нужный сценарий в виджете.
Для результатов я выбрал интерактивный виджет. Тестов оказалось много, и каждую комбинацию я повторял трижды. Основная схема выглядела так:
- 3 формата файлов
- 2 устройства с разной производительностью
- 3 запуска каждого теста
В описании работы указаны 54 экспорта в основной серии и более 200 измерений с учётом дополнительных проверок. Вместо просмотра множества таблиц можно выбрать нужный сценарий в виджете.
Публичный виджет содержит 15 усреднённых сценариев, а не отдельные результаты всех 54 экспортов или более 200 измерений. По опубликованным данным нельзя восстановить журнал этих запусков.
Ниже представлен опубликованный набор данных 2025 года. Можно выбрать существующие сочетания формата, устройства и размера модели. Таблица и файлы под виджетом содержат те же значения с пояснениями границ замера и недоступных показателей. Будущие повторные тесты следует выпускать отдельными датированными версиями.
Для тестов я использовал тот же комплексный проект, который уже показывал: архитектура, конструкции и инженерные системы. Я подготовил три его варианта, лёгкий, средний и тяжёлый, с разными размерами файлов и количеством элементов.
(Сама модель загружается небыстро. Я также проверяю Speckle Viewer, но это тема отдельной публикации.)
(Сама модель загружается небыстро. Я также проверяю Speckle Viewer, но это тема отдельной публикации.)
Версии коннектора и приложений.
В исследовании использовался Speckle Connector 3.10. Версия 3.11 появилась, когда я заканчивал исходные измерения в 2025 году. Это исторический контекст, а не указание текущей версии. В статье используются Autodesk Revit 2026 и Navisworks 2025 с установленными на тот момент обновлениями, а IFC загружается через онлайн-загрузчик. Подготовка доступной выгрузки не означает повторного тестирования новых версий коннектора.
В исследовании использовался Speckle Connector 3.10. Версия 3.11 появилась, когда я заканчивал исходные измерения в 2025 году. Это исторический контекст, а не указание текущей версии. В статье используются Autodesk Revit 2026 и Navisworks 2025 с установленными на тот момент обновлениями, а IFC загружается через онлайн-загрузчик. Подготовка доступной выгрузки не означает повторного тестирования новых версий коннектора.
Результаты тестирования
В опубликованных сценариях различаются представление модели и полная рабочая конфигурация. ПК использовал Ethernet, а ноутбук 4G, поэтому это исследование не отделяет влияние оборудования от влияния сети. Прежде чем сравнивать время полного экспорта, нужно также убедиться, что измерены одинаковые этапы.
Форматы
В опубликованных сценариях на ПК RVT показал меньшее время, чем NWC.
Исходное исследование касалось первой загрузки и рассматривало обработку повторяющейся геометрии в Connector 3.10. Эти наблюдения не выделяют вклад отдельной оптимизации и не доказывают, что RVT быстрее на любом устройстве.
Небольшой файл NWC не обязательно означает короткий экспорт.
Один проект представлен разным числом объектов в разных форматах. Размер файла сам по себе не описывает объём обработки.
IFC обрабатывается на сервере.
Это может перенести часть работы из локального приложения в облако. Однако примечание к малому IFC прямо указывает, что отсчёт начинается после загрузки. Сравнивать это значение с полным временем передачи другого формата можно только после согласования этапов замера. Значения CPU и RAM облачного обработчика в опубликованных данных недоступны.
Исходное исследование касалось первой загрузки и рассматривало обработку повторяющейся геометрии в Connector 3.10. Эти наблюдения не выделяют вклад отдельной оптимизации и не доказывают, что RVT быстрее на любом устройстве.
Небольшой файл NWC не обязательно означает короткий экспорт.
Один проект представлен разным числом объектов в разных форматах. Размер файла сам по себе не описывает объём обработки.
IFC обрабатывается на сервере.
Это может перенести часть работы из локального приложения в облако. Однако примечание к малому IFC прямо указывает, что отсчёт начинается после загрузки. Сравнивать это значение с полным временем передачи другого формата можно только после согласования этапов замера. Значения CPU и RAM облачного обработчика в опубликованных данных недоступны.
Устройства
ПК с Ethernet оказался быстрее ноутбука с 4G в большинстве опубликованных пар.
Это сравнение двух полных конфигураций, а не отдельно оборудования или сети.
Для тяжёлого RVT время различается в 15 раз.
Опубликованы значения 196 секунд на ПК и 2940 секунд на ноутбуке. Соотношение относится именно к этим двум условиям и не является универсальной оценкой разницы между ноутбуком и настольным компьютером.
Виджет показывает максимальную скорость сети как пиковое значение. Пик отличается от средней скорости и сам по себе не определяет полное время сценария.
Это сравнение двух полных конфигураций, а не отдельно оборудования или сети.
Для тяжёлого RVT время различается в 15 раз.
Опубликованы значения 196 секунд на ПК и 2940 секунд на ноутбуке. Соотношение относится именно к этим двум условиям и не является универсальной оценкой разницы между ноутбуком и настольным компьютером.
Виджет показывает максимальную скорость сети как пиковое значение. Пик отличается от средней скорости и сам по себе не определяет полное время сценария.
Дополнительные наблюдения
Проверенные модели NWC содержат много объектов при небольшом размере файлов. В исходной статье описаны примерно 3-20 MB и 12-50 тысяч элементов. Поэтому сравнения только по размеру недостаточно.
Для тяжёлого RVT на ПК опубликовано около 14 GB использования RAM. Это результат конкретного сценария на ПК, а не свидетельство использования памяти или файла подкачки на ноутбуке. Для проверки этих механизмов нужны отдельные журналы ресурсов.
В некоторых записях загрузки пиковая скорость сети превышает 100 Mbps. Это пиковые значения, а не отдельный замер ускорения, вызванного сменой подключения.
Для тяжёлого RVT на ПК опубликовано около 14 GB использования RAM. Это результат конкретного сценария на ПК, а не свидетельство использования памяти или файла подкачки на ноутбуке. Для проверки этих механизмов нужны отдельные журналы ресурсов.
В некоторых записях загрузки пиковая скорость сети превышает 100 Mbps. Это пиковые значения, а не отдельный замер ускорения, вызванного сменой подключения.
Практические выводы
- Для исходной модели Revit начните с проверки нативного коннектора в собственном рабочем процессе.
- Рассмотрите онлайн-загрузчик IFC, когда полезна серверная обработка, но включайте подготовку IFC и загрузку файла в сравнение полного процесса.
- Используйте NWC там, где этого требует координация.
- Для больших передач выбирайте стабильное подключение. Чтобы измерить влияние сети, сравнивайте подключения на одном устройстве.
- В этом эксперименте проверялся Connector 3.10 в 2025 году. Новые версии нужно сравнивать при одинаковых условиях; статья не является рекомендацией текущего релиза.
Почему IFC не всегда мой первый выбор для передачи в Speckle
Хотя облачный загрузчик IFC переносит обработку с локального компьютера на сервер, в своём рабочем процессе я не считаю IFC основным вариантом передачи моделей в Speckle.
- IFC не является нативным форматом. Он уже представляет собой экспорт из другого приложения. Преобразование добавляет время, сложность и риск потери части данных.
- Экспорт IFC из Revit, Archicad, Tekla и других авторских приложений требует отдельного времени. Подготовка IFC является самостоятельным этапом, который нужно измерять. Серверное время обработки само по себе не доказывает выигрыш во всём процессе.
- Дополнительная нагрузка и расход ресурсов. Создание IFC нагружает CPU и RAM и может замедлять интерфейс. Для крупных моделей это самостоятельная операция рабочего процесса.
- Структура данных сохраняется не всегда. Преобразование может изменить геометрию, набор параметров и представление объектов. Результат следует проверить на соответствие исходной модели.
Поэтому даже при облачной обработке Speckle я рассматриваю IFC как дополнительный вариант, особенно когда:
- локальный компьютер ограничен по ресурсам,
- модель очень велика,
- часть обработки нужно перенести с ПК на сервер.
В своём процессе я обычно сначала проверяю нативный коннектор Revit и использую NWC там, где этого требует координация. Подходящий вариант зависит от исходного приложения, модели и информации, которую нужно сохранить при передаче.
Опубликованные наблюдения отражают условия 2025 года. В следующих сравнениях полезно отдельно фиксировать подготовку, загрузку и обработку, сохранять журналы каждого запуска и подключать устройства к одной сети при проверке влияния оборудования. Новым версиям коннекторов нужен собственный датированный набор данных. Доступная таблица и файлы сохраняют исторический эксперимент, не представляя его новым тестом.