jonathon
27 November 2025 13:56
1
So @Community Community StandUp . Not a retro. Just an hour with @Nikos and the team guiding us through a year where Speckle released so much, so quickly, that even the fast bits felt slow by comparison.
Workspaces matured. Markup arrived. Saved Views became so easy to use that it felt like they had always been there, and Presentations slotted neatly on top. Intelligence dashboards became the thing you proudly show to clients, even though it took three clicks instead of the previous six-hour InDesign marathon. Advanced filters opened up real model interrogation. specklepy 3 launched. Connectors improved everywhere. ACC integration moved forward. Model Validation became something normal people can use. Textures are coming to the web viewer. The Viewer got faster , which you overlooked because you uploaded models the size of small towns. Docs finally got overdue love. The website got rebuilt and then rebuilt again. And Automate shifted backstage, powering the magic behind the blue publish button without asking you to understand pipelines.
And Issues ; well, Issues will be launched, almost launched, or launched just before we go live. This is the Speckle Community StandUp tradition. Over to you @Nikos
Because 2025 looked like separate things happening in parallel.
One system. One identity. One set of fingerprints. One motion.
Which brings us back to the only definition that survived the year intact.
Join us. See the whole picture. Leave feeling a little more in control.
Register and tune in:https://streamyard.com/watch/d7XUzFCP95ZA
PS: Things we learned this year:
Dashboards become universally loved the moment they open quickly.
The Viewer can triple in speed, and the community will respond by uploading a model the size of a postal district.
And @haitheredavid owns a suit, which none of us had on our 2025 bingo cards.
Community stand-ups only work because the learning goes both ways.you
9 Likes
mirna
27 November 2025 14:31
3
If you ever cut your hair, Jonathon might just lose it, apparently! So, save it for a good moment.
3 Likes
jonathon
9 December 2025 12:36
4
Two more sleeps to the end-of the-world Community Standup!
1 Like
Hi everyone!
I found a couple of discussions related to performance when reading large IFC files:
opened 11:19PM - 16 Jul 24 UTC
IfcOpenShell-Core
There were two articles recently:
https://www.linkedin.com/pulse/10x-faster-i… fc-file-parsing-christopher-diggins-ljobe/
https://www.linkedin.com/pulse/worlds-fastest-ifc-loaderparser-christopher-diggins-1ynte/
I've summarised the times claimed by various people tesing:
Filesize MB | Ara3D | XBim | GeometryGym | IfcOpenShell | web-ifc | Hypar
--- | --- | --- | --- | --- | --- | ---
1.2GB across 49 files (Chris) | 2.7 | 92 | 900+ | - | - | -
1.2GB (Tom) | - | - | - | - | 3 | -
450M (Chris) | 5.4 | - | - | 100 | - | -
334M (Moult) | - | - | - | 15 | - | -
88M (Chris) | 0.35 | 3.5 | 11.68 | - | - | 38.7
88M (Moult) | - | - | - | 3.8 | - | -
68M (Moult) | - | - | - | 2.3 | - | -
68M (RyugaRyuzaki) | - | - | - | 6 | - | -
From the article:
> One of my benchmarks involves opening 49 different IFC files, each between 10 and 50MB (for a total of 1.2GB if data) and counting the number of door entities (IFCDOOR) in each one. This is parallelized over the set of files.
>
> I've compared my library with the popular open-source C# libraries [XBim](https://docs.xbim.net/) and [GeometryGym](https://geometrygym.wordpress.com/), and here the results:
>
> Ara 3D - 2.7 seconds
> XBim - 1 minute 32 seconds
> GeometryGym - over 15 minutes
>
> Here are some of the techniques I used:
>
> Minimize the size and frequency of memory allocation
> Keep data contiguous (e.g., arrays of structs)
> Advance through data using pointers
> Delay the parsing of text representation into binary, until needed
> Hand write a parser (instead of using a parsing library)
> Do lots of testing, measuring, and logging to determine bottlenecks and perform experiments.
Another quote (from the comments of [this post](https://www.linkedin.com/posts/cdiggins_the-ara-3d-ifc-file-parsing-library-is-progressing-activity-7216529136322838528-lkrc?utm_source=share&utm_medium=member_desktop):
> I tried the Python bindings of IfcOpenShell and **it took 1m40s compared to 5.4s** using Ara 3D to open a 450MB file and count 7 doors!
>
> Because of the simplicity of the code, I don't think the Python bindings are the bottleneck, but can't know for sure. I tried compiling the C++ sources, but it is crazy complicated, took over an hour to run the makefile.
To clarify, this is what he is testing:
More quotes:
> Hi Christopher. I'm happy to report that the cpp code of web-ifc parser (or at least the version I have from feb 23) can parse 1.2GB of IFC data, and count the doors (and in fact produce a complete index into the ifc file) in 3 seconds on my terrible laptop. In addition, for the simple act of parsing the IFC file, it is in fact very mature.
>
> Also, it is completely open source, so anyone can go check it out and use it for free :-)
>
> Since you're interested in the topic, I would suggest looking at simdjson and applying the same techniques to parsing IFC, which I'm sure will push it far past the 3 seconds we're getting now.
More quotes:
> Hi Paul, thanks for the support. I'm not validating any particular schema for now, I just check that it is a valid STEP file, and link up the entities as they occur. I will be using it to create a tool for people to validate their own BIM standards like Solibri. I'm probably still missing parts of the STEP standard, but I have a continuously growing test suite of over a hundred IFC files. Private unfortunately, as it is related to a very large project in progress. I open and parse each file on its own thread, but plan on introducing multithreading in single file parsing later on.
Thoughts? I'd say on my computer IfcOpenShell definitely cannot open 1.2GB in 3 seconds :)
Just ran a test and it takes 15s to load 334MB on my machine and count 157 doors. I'm totally fine with that but curious why other people are getting other results.
opened 09:12AM - 16 May 25 UTC
IfcOpenShell-Core
### Bug Description
I am encountering a significant performance issue with IfcO… penShell when processing IFC files, especially when compared to XBim. My program, written in C++ and using IfcOpenShell, runs much slower than XBim for files of various sizes (12MB, 80MB, 200MB, and 700MB). Since both libraries utilize C++ and OpenCascade for geometry processing, I expected their performance to be more comparable, but IfcOpenShell consistently underperforms.
Here’s how to reproduce the issue:
Compile and run the provided C++ code with IfcOpenShell.
Use an IFC file (e.g., "D:/Trachhaha/Code/file200Mb.ifc") as input.
Measure the time taken for file loading and the iteration process.
Performance Data:
12MB: IfcOpenShell (222s) vs XBim (2s)
80MB: IfcOpenShell (242s) vs XBim (3s)
200MB: IfcOpenShell (70s) vs XBim (20s)
700MB: IfcOpenShell (288s) vs XBim (46s)
Performance Breakdown:
For smaller files (12MB and 80MB), the while(iterator.next()) loop accounts for 98% of the total processing time.
For larger files (200MB and 700MB), the file opening process (IfcParse::IfcFile) takes up approximately 40% of the total time.
Attempts at Optimization:
I’ve explored several alternatives to improve performance, but none have been successful:
CGAL: Encountered runtime errors.
cgal-simple: Performance was similar to hybrid-cgal-simple-opencascade.
OpenCascade alone: Ran extremely slowly, worse than IfcOpenShell.
Request for Help:
I need assistance in optimizing IfcOpenShell to approach XBim’s performance levels. Specifically, I’d like guidance on:
Reducing the time spent in the while(iterator.next()) loop for smaller files.
Speeding up the file opening process for larger files.
Any configuration tweaks, alternative approaches, or optimizations that could improve overall performance.
Since XBim achieves much faster results using C++ and OpenCascade, I believe there’s potential for IfcOpenShell to improve in these areas. Please advise on how I can enhance the speed of my program.
### Attachments
https://drive.google.com/drive/folders/1gd1uKXPl_FYwQyrLma5j1y5sm46pO9Hf?usp=drive_link
### Debug and Error Output
```true
int main() {
auto start = std::chrono::high_resolution_clock::now();
std::string filePath = "D:/Trachhaha/Code/file200Mb.ifc";
IfcParse::IfcFile file(filePath);
// Geometry processing settings
ifcopenshell::geometry::Settings settings;
settings.set("use-world-coords", true); // Use global coordinates
settings.set("weld-vertices", false); // Preserve vertices for normals
settings.set("apply-default-materials", false); // No default materials needed
settings.set("convert-back-units", true); // Convert units back to IFC
int num_threads = std::thread::hardware_concurrency();
IfcGeom::Iterator iterator("hybrid-cgal-simple-opencascade", settings, &file, num_threads);
if (!iterator.initialize()) {
std::cerr << "Failed to initialize iterator" << std::endl;
return 0;
}
auto end0 = std::chrono::high_resolution_clock::now();
std::chrono::duration<double> elapsed1 = end0 - start;
std::cout << "\nTime1 (file loading): " << elapsed1.count() << " s ";
auto start2 = std::chrono::high_resolution_clock::now();
int count = 0;
do {
int progress = iterator.progress();
if (progress % 5 == 0 && progress != count) {
std::cout << "\nProgress: " << progress;
count = progress;
}
// Placeholder for handling instance and geometry data
//struct ShapeGeometryData {
// int label;
// std::vector<double> vertices;
// std::vector<double> normals;
// std::vector<int> indices;
// BoundingBox localBoundingBox;
//};
//struct ShapeInstanceData {
// int InstanceLabel;
// std::string ExpressTypeId;
// int IfcProductLabel;
// int StyleLabel;
// int ShapeGeometryLabel;
// int RepresentationContext;
// RepresentationType RepresentationType;
// Eigen::Matrix4d Transformation;
// BoundingBox globalBoundingBox;
// std::string IfcType;
// std::string Guid;
//};
} while (iterator.next());
auto end2 = std::chrono::high_resolution_clock::now();
std::chrono::duration<double> elapsed2 = end2 - start2;
std::cout << "\nTime2 (iteration): " << elapsed2.count() << " s ";
std::chrono::duration<double> elapsed3 = end2 - start;
std::cout << "\nTotal Time: " << elapsed3.count() << " s ";
return 0;
}
Additional Details:
IfcOpenShell Version: [V0.8.0]
Operating System: [Windows 10]
Compiler: [Visua studio 2022]
Hardware: [Intel i7-11th, 32GB RAM]
```
opened 11:18AM - 21 Oct 23 UTC
closed 02:57AM - 25 Sep 24 UTC
IfcOpenShell-Core
I try reading geometry in ifcopenshell and comparing with other libraries, it se… ems it might be slower than web-ifc and XBIM, Here is the comparison:
You can test repo :https://github.com/RyugaRyuzaki/ifc-parser-compare
Jedd
25 December 2025 21:15
9
Hi @Miguel_Gutierrez2 ,
This is a really good question, I think you should have a read of this post we made earlier in the year when we made the switch.
We learned the hard way that, for Speckle’s IFC importer, reliability was far more important than raw performance.
Going into our new IfcOpenshell based importer, we knew that we would require a more powerful machine in order to match the performance of our older importer.
Since that post we’ve found a few more tricks to make our importer even faster and more memory efficient. So any numbers we quoted in that post are no longer accurate.
3 Likes
Thanks for the context @Jedd , that helps a lot!
I’ve run into similar reliability problems with web-ifc in some cases, like the ones discussed in this thread am currently contributing to web-ifc library and fixing these kinds of issues.
However, it looks like IfcOpenShell is more actively maintained and having more contributors definitely makes it a more reliable option. So, good choice there!
