Blog-NikoG

Testing the Performance of Speckle Connectors

Testing the Performance of Speckle Connectors

Today’s post is a bit different from what I usually publish. Normally, I dive deep into topics, break everything down with charts and tables, compare approaches, and highlight all the details that tend to stay behind the scenes. This time, I decided to take another route.

We’re talking about Speckle, and more specifically, about the Speckle Connectors for Revit, Navisworks, and IFC. Why these formats? The answer is simple - I use them every day, and I know exactly how they behave in real project conditions.
A little while ago on LinkedIn, I mentioned that I was planning a large-scale test for Speckle. The deeper I went, the clearer it became that this topic can’t fit into “just one post”. Speckle isn’t just a tool, it’s essentially an ecosystem. So I chose to start where anyone would start - with the connectors, because they are the entry point for exporting your model.

You won’t see any charts in this article. The reason is straightforward: charts are boring, and the number of tests I ran turned out to be too large. To eliminate randomness, I repeated each scenario three times. Here’s what the final testing setup looked like:

  • 3 file formats
  • 2 devices with different performance levels
  • 3 runs for every test

In total, that’s 54 exports within the main series alone. With additional checks included, the dataset expanded to over 200 measurements. Going through endless tables is not enjoyable, so I created a compact, interactive widget that presents the results more conveniently.

The complete work described here included additional checks. The public widget currently exposes 15 scenario averages, not the individual run log for all 54 exports or 200-plus measurements. The published data do not allow those separate runs to be reconstructed.

The widget below presents the published 2025 dataset. You can filter its existing combinations of format, device and model size. The table and downloads below the widget expose the same scenario values with notes on timing and unavailable measurements. Future retests should be released as separately dated versions.

Speckle scenario benchmarks

Explore real measurements for different formats, devices, and model sizes.

Status: initializing…

Loading benchmark data…

Results, downloads and comparison limits

These 15 scenarios come from the published dataset for Speckle Connector 3.10. They are a readable export of the 2025 experiment, not a new test. The article reports using Revit 2026 and Navisworks 2025.

Timing scope matters: the small IFC scenario explicitly starts timing after upload, during server processing. Matching timing boundaries have not been established for the other rows. Treat the durations as reported scenario times, not automatically comparable end-to-end export times across all formats.

15 published scenarios. S, M and L identify model-size categories.
IDFormatDevice and connectionSizeTime, sCPU, %RAM, MBPeak network, Mbps
1RVTPC / EthernetS4618.194,157.0936.1
2IFCCloud uploader / EthernetS82 *Not availableNot available126.78
3NWCPC / EthernetS788.111,615.6832.14
4RVTPC / EthernetM8717.98,195.2641.27
5NWCPC / EthernetM1678.052,453.8944.89
6IFCCloud uploader / EthernetM131Not availableNot available131.98
7RVTNotebook / 4GL294029.45,877.2318.95
8RVTPC / EthernetL19619.3514,362.0856.76
9NWCPC / EthernetL4658.115,025.1841.63
10IFCCloud uploader / EthernetL562Not availableNot available182.4
11NWCNotebook / 4GS20426.811,217.7218.37
12RVTNotebook / 4GS27431.773,841.1922.34
13RVTNotebook / 4GM103228.325,436.1716.29
14NWCNotebook / 4GL143720.453,278.8312.52
15NWCNotebook / 4GM1678.052,453.8913.78

* Small IFC: post-upload time. CPU is average utilization; network is peak throughput. File-size and memory units retain the source labels.

How to read these results

  • The PC used Ethernet and the notebook used 4G. These observations compare complete working setups; they do not isolate the effects of hardware and network.
  • The source describes values as three-run averages. Individual repeats are not included, so their variation cannot be reconstructed. This dataset contains 15 scenarios, not the complete log of every measurement mentioned in the article.
  • Verified cloud CPU and RAM readings are not available in the published source. This edition replaces their zero placeholders with labelled nulls and preserves all other numbers. The original published version remains linked below.
  • The two medium NWC scenarios share time, average network, CPU and RAM values. They are retained as published; the original run logs would be needed to justify a correction.
  • Most rows are dated 12 or 13 November 2025. The heavy notebook RVT scenario has no date in the source. The table rounds display to two decimals; the downloads preserve the published precision.

Download the data

Open the CSV in a spreadsheet. The JSON also records provenance and missing-value handling. These are summary data, not individual run logs.

Download CSVDownload JSON

Original published JSON, unchanged

How to cite

Gamsakhurdiya, N. (2025). Testing the Performance of Speckle Connectors. Speckle Connector 3.10, published scenario averages. Readable export readable-1.0, prepared 6 November 2026.
https://nikog.net/blog/speckle-connector-performance-test

Author: Niko Gamsakhurdiya. The export preparation date does not change the experiment date.

I used the same model I’ve shown before - a full, complex project that includes architecture, structure, and MEP. To avoid inconsistencies, I prepared three variations of it: a light, a medium, and a heavy version, each differing in file size and element count.

(To be honest, the model itself loads slowly, and I’m currently testing the Speckle Viewer as well - that will be a separate post.)
Connector and application versions.

This study used Speckle Connector 3.10. Version 3.11 appeared while I was finishing the original measurements in 2025; that is historical context, not a statement of the current version. The article reports Autodesk Revit 2026 and Navisworks 2025 with the updates installed at the time, and IFC uploads through the online uploader. The readable export does not constitute a retest of later connector releases.

Test Summary:

The published scenarios show differences between file representations and complete working setups. The PC used Ethernet and the notebook used 4G, so this design does not separate hardware effects from network effects. Timing boundaries also need to match before durations can be treated as comparable end-to-end exports.

Formats

RVT recorded shorter times than NWC in the published PC scenarios.
The original study focused on first-time uploads and discussed Connector 3.10's handling of repeated geometry. These observations do not isolate the contribution of any one optimization or establish that RVT is fastest on every device.

A small NWC file does not necessarily imply a short export.
The same project is represented by different numbers of objects in different formats. File size alone does not describe the processing work.

IFC uses a server-side processing path.
This can move work away from the local application. However, the small IFC note explicitly starts its timer after upload. Do not compare that number with another format as a complete end-to-end transfer without aligning the measured phases. Cloud CPU and RAM readings are not available in the published data.

Devices

The PC with Ethernet was faster than the notebook with 4G in most published pairs.
This compares two complete configurations, not hardware alone or the network alone.

The heavy RVT scenario differs by a factor of 15.
The published values are 196 seconds on the PC and 2,940 seconds on the notebook. That ratio applies to those two conditions. It is not a universal laptop-versus-desktop multiplier.

The widget labels maximum network throughput as a peak. A peak speed is different from average throughput and does not by itself determine total scenario time.

A few interesting observations:

The tested NWC models contain many objects despite their small file sizes. The original study describes roughly 3 to 20 MB and 12 to 50 thousand elements, illustrating why size alone is not a sufficient comparison.

The heavy RVT PC scenario reports about 14 GB of RAM usage. This is a result for that PC scenario, not evidence of the notebook's RAM use or paging behaviour. Individual resource traces would be needed to assess those mechanisms.

Some published upload records have network peaks above 100 Mbps. These are peak readings, not an isolated measurement of the speed improvement caused by the connection.

Practical takeaways

  • For a Revit source model, start by evaluating the native connector in your own workflow.
  • Consider the IFC online uploader when server-side processing is useful, but include IFC preparation and upload when comparing the complete workflow.
  • Use NWC where coordination requirements make it appropriate.
  • Prefer a stable connection for large transfers. To measure a network effect, compare connections on the same device.
  • This experiment tested Connector 3.10 in 2025. Check later versions under matching conditions rather than treating this as a current release recommendation.

Why I still don’t recommend using IFC for exporting to Speckle

Even though the IFC cloud uploader delivers predictable results and offloads processing from the local machine, I still wouldn’t consider IFC a primary format for exporting models to Speckle.
  1. IFC is not a native format. It’s already an export from another application. Any conversion adds time, complexity, and the risk of losing part of the data.
  2. Exporting IFC from Revit, Archicad, Tekla, or any other authoring tool takes noticeably longer. IFC preparation adds a stage that must be measured; server-side processing time alone does not establish an end-to-end saving.
  3. Additional load and resource consumption. Generating IFC is a heavy operation: it stresses the CPU, consumes a lot of RAM, and can even freeze the interface. With large models, this becomes a separate workflow stage on its own.
  4. Data structure isn’t always preserved. IFC often simplifies or transforms geometry. Some elements appear as extra, some native parameters disappear, and the resulting structure doesn’t always match the source model.
That’s why, even though Speckle handles IFC quite well through the cloud, I would still treat this format only as a fallback option, to be used when:
  1. your local machine is too weak,
  2. the model is extremely large,
  3. you need to offload as much processing from the PC as possible.
In my workflow, I therefore usually evaluate the native Revit connector first and use NWC where coordination requires it. The appropriate route still depends on the source application, the model and the information that must survive the transfer.
These published observations are a snapshot of the 2025 conditions. Further comparisons should separate preparation, upload and processing, retain individual run logs, and compare devices on the same network when testing a hardware effect. Later connector results should have their own dated dataset. The readable table and downloads preserve this historical experiment rather than relabelling it as a new test.
2025-11-13 13:57 BIM Revit