Opening large step files takes a very long time


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

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?

best regards


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 to send it in to 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.

@chuck can you comment?

…and from my perspective, I typically have no interest in the blocks. First order of business is to explode and purge them.

@chuck Would be nice to be able to toggle this off, as it would remain off almost all the time in my work.


1 Like

Same thing here…

Hi Brian,

thank you for looking into this!

In response also to the other comments below: The first thing I do when the STEP file is opened is to explode and purge all the blocks :slight_smile:

So I’ll definitely try and avoid the creation of blocks at the source, and I’ll have a look at V6 as well.

I’ll let you know how I get on. At the moment all of my PC’s are busy opening STEP files… ;-D

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.

Thanks, Chuck.

I think this works -

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…


Ah, that sound familiar now…yea, I think the ‘right’ command line option was the ticket. Thanks!

Yeah, same here.


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 :slight_smile:

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.

Thank you for the good advice!

1 Like

Thanks for the update Ben! @chuck please let me know if you need me to file anything regarding

@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.


RH-42682 is fixed in the latest Service Release Candidate