Loading optimization
See original GitHub issueThis issue refers to how fast the scenes load. In other words, how fast can we parse an IFC file. Check out https://github.com/agviegas/IFC.js/issues/33 for the related geometry optimization
issue.
I have implemented web workers to allow for “multithreading”. Here’s a link to my fork. I have documented my thoughts here and here.
TL;DR:
The next step is to figure out how to implement my (or a similar) solution into this project. There are many ways to do this.
I suggest we/you release the first version of IFC.js
and THEN implement web worker support.
Yes - performance is an important factor. But, I think it’s more important to support the most useful IFC2x3 classes.
Anyways, that’s just my thoughts. I’m open to suggestion and I encourage others to experiment with this as well.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:7
I’m closing this issue for now, as the main responsible for optimization now are both web-ifc-three and web-ifc. Feel free to drop new ideas there to make this even faster!
I noticed that my multi-web-worker example didn’t perform as well with the latest changes (e.g. https://github.com/agviegas/IFC.js/commit/b41d41b60188d255ef0da7b9470200060a148b14, https://github.com/agviegas/IFC.js/commit/453640866ed823c91913a35d75026e36d2257dd0, https://github.com/agviegas/IFC.js/commit/d92e8f87211f87d798c10b853f446c0ee900a579).
There is a time penalty for starting an additional Web Worker. My guess is that the parser is so much faster now that there’s no performance gain to be made. This might be different for large (>200MB) IFC files.
I will experiment with this some more 😄