I’d like to find out why opening large STEP files takes such a long time. It looks to me like the time it takes increases exponentially with file size:
STEP file size [MB]_____time to open [minutes]
11.16 0____________________0.2
17.393_____________________1
32.565_____________________2
54.374____________________28
89.698____________________74
118.629__________________292
Is this to be expected and does it make sense to someone who knows what happens during the process?
The hardware resources do not appear to be used fully: CPU is at 12% and Memory around 20%.
Do I have any options of speeding up this process apart from looking at the actual contents of the STEP file being opened?
Thanks for the report and question Ben. Can you send in one of the step files that you’re waiting for the longest? You can private message me here or use www.rhino3d.com/upload to send it in to tech@mcneel.com mentioning me BrianJ and I’ll take a look for comparison. One thought is that you may be running into a slowdown due to RAM usage and the subsequent paging file size set in Windows.
If you can, also try the Rhino v6 beta listed here on the forum. In my tests it’s faster by around 30% or more at loading step files. I’d be curious to hear what you get for load times with these files.
Thanks for sending in the file Ben. The file is 128mb and opens in the v6 beta in 10 minutes here so a marked improvement in speed but still not fast.
I found that the file is one block instance when opened with 14,717 nested blocks with some having their own nested blocks as well. This seems to be the slowdown when parsing the stp file. You can use Explode to explode one level of the nested block structure or ExplodeBlock to explode all of the nested blocks. If I use ExplodeBlock and save out a stp file, it opens back in the v6 beta in 15 seconds. Check if you can save out the stp from the originating app without the nested blocks unless that messes up your workflow.
As far as I understand, it is Rhino that creates the blocks when importing a STEP file. Chuck wrote something about making a test command to turn that off - that thread is on my to-do list and I’m not going to try to go through all that today…
Maybe I’m not totally right then but the ExplodeBlock>save to step test doesn’t yield more blocks when opened again. However, if I just use Explode and explode only the parent block and save it out as a step, that version loads in 30 seconds in v6 but does end up creating a new parent block of the 17,717 block still present in the file. In any case, it’s still a speed up and perhaps there is a way to limit the nesting in the originating app to find a similar gain.
I just read through that thread from last Spring and couldn’t find any conclusion on whether or not @pascal 's script solved the problem. Maybe I missed it. The more I think about it, the more I believe a post-process script is the right way to handle this. It seems there are too many potential desired formats to put as options in the import dialog. I could be wrong, of course.
That said, none of this would solve the speed issue. I’d guess that is due to an inefficient nested looping through all the objects somewhere.
Thanks Chuck.
I leave a few posts unread on that thread from last Spring to keep it on my to-do list but I remember trying to make lists in Excel for long nested layer lists in NX before export to STEP to be able to check against Pascal’s script. There were some issues but I never got through that…
At any rate, as long as the speed issue isn’t caused by making the nested blocks, I don’t terribly mind running through explode and purge for the time being.
Now that you mention it, I do vaguely remember playing with that script. I think I either fumbled with it and it failed, or fumbled further and it worked. Not sure.
My problem is to remember the script. I think I saved or bookmarked filed it, and I’ll likely just continue to explode and purge manually, like @wim. If I did receive a monster file where manual was a hassle, then hopefully I’d remember to dig up the script and hopefully it works…
I see what you are saying about the import dialog. Could there be a global switch (off by default?) for all import formats to omit block creation? If that was easy to implement I’d probably toggle it to skip block creation.
Related to OP, received two 500MB STEP files recently. Took way more than 10 min… like go to lunch. Other apps took a while too, but seemingly not as long. I did not time them, however.
ExplodeBlocksToLayers.rhp (14.5 KB)
You most likely want the non-default command line option, but… if you have many nestings in the file, it could make for an unwieldy pile of layers. And on very large files, I don’t know how fast it will be…
Wow!! Brian! I just opened a 540MB STEP file in 2 hrs with the V6 beta!! (roughly, I was out for lunch while it finished)
A different PC is still working on the same file using V5 and it’s been at it for 4.5 days now. I’ll let it know that it can stop. Good effort, though
This makes me very happy.
I suppose it makes the block thing almost irrelevant, but if that can also be optimized then the files will open before I have finished clicking on them I’m sure.
@BrianJ I did find a place where there’s a really stupid sorting that would be really inefficient for large assemblies, and am working now to fix it. It’s hard to tell at this point how much it will speed things up, but it could be significant. I will file a report.
So far, I’ve removed several bottlenecks in the reading of BenH’s huge Step file. The 15 seconds it takes until the “Begin parsing file” goes away can’t be changed.
Before my changes, there were about 6 minutes spent before the “Adding STEP objects to Rhino” appeared. This is now down to 11 seconds.
Before changes, the “Adding…” message was up for about 4 minutes. That’s now 2.5 minutes. It will take some changes outside the STEP import code to shorten the Adding stage, but I think it can be dropped down to a few seconds if I understand the problem correctly.
My changes will not be available immediately in the Beta, but should be available soon.