Rhino 8 is so slow it's practically unusable

Rhino Rhino for Windows
,
1

Simple commands like isolate, isolateLock, or even copy-paste would take 1 min or longer to execute, if at all - in 5 out of 10 cases, it simply freezes and crashes the app.

On serious professional architectural projects, this is making the software practically unusable.

Someone is going to jump out and say: hey, you could split heavy models into smaller ones and worksession them together. However, in the reality of fast-paced frontline architectural practices, this is often simply not practical. It would take you 20min to even assemble the model, every time you edit the models, and for every option/iteration - it simply doesn’t work like that if you are in any serious firms.

Besides, if I am forced to do that, what’s the point of having these commands in the first place?

Even scrolling down the layer menu would freeze your software for 30s it’s absolutely unacceptable.

After over a dozen of crashes in less than a week, I have already hardwired this reflex in me where whenever I want to use isolate/isolateLock, I would intuitively open a new model, paste my target edit parts inside, edit, and copy-paste back into the main model. Whereas in previous builds that were ACTUALLY FUNCTIONAL, I enter isolate, edit, unisolate, done.

What is going on??

For designers navigating between complex technical, design, and representation problems, maintaining the congituous creative flow is essential. If the goal is to kill your competitive edge against Autodesk, etc. with how responsive Rhino used to be, you have been quite successful.

I don’t know what corporate non-tech PM you guys have who poisoned the software development decisions with all these extremely heavy state management that don’t do anything but add computation overhead, crash workstations, and decimate productivity, and I am definitely not expecting this to be solved the way things have moved since two builds ago. I just want to say: honestly, this is stupid.

2

Hi Wang, I am curious about the file size you are working with most the time?----Mark

3

I had similar problems in the past and in the end the problem was a lot of duplicated geometry inside one of the blocks I was using. It was a simple geometry of around 200 faces but it was imported from solidworks, and turns out it had like 2000 or so duplicated breps inside of it, of the same geometry again and again.

Another time it happened with curves, hundreds of curves duplicated from an imported dwg.

4

I have no idea how that rant is supposed to help anyone figure out what the issue is, there is less than zero helpful information, also we’re all pros here going on about how serious you are like “Do you know who I am??” is just cringe.

5

Hi wang_minquan,

Lets get your systemInfo and an example file, if you can’t post here please zip and send to https://www.rhino3d.com/upload

6

Did you read the post? This thread is NOT supposed to solve a problem, because I am NOT expecting the problem to be solved. The intention of this post is to POINT OUT an important issue in software development direction, namely: prioritizing excessively complicated state management over performance and stability. I am a professional architect working with ~1GB architectural models on a daily basis, which is the nature of the corporate work I have to go through. If you can identify a quote on me claiming myself to be some 3D guru or archi grandmaster please feel free to direct me to the quote. With that said, I have been using Rhino for almost 15 years, and I can clearly identify that with each build the software gets slower - it’s clearly not a problem of the files, as it’s the same set of files. Again, just in case more assaults at me stating my long term experience with the software (which I am sure is modest in comparison to many on this forum) is going to come, the point of this statement is NOT to brag about my expertise but to point out that with a considerably long exposure to the software we are stuck with to make a living with, I can tell that the performance recession has been happening steadily and consistently, to the point of finally rendering a coherent workflow impossible.

7

Okay so you haven’t done anything to try to help anyone figure out what’s going on, you just wanted to present some theory you have about software development. I dunno, you could try…literally anything else. Rhino has not in fact gotten “so slow it’s practically unusable” for everyone working with large files, actually there are several ways it’s gotten better, and there are so many factors that could affect such an issue that just going “bleh dumb Rhino devs” is really silly.

8

Hi @Wang_Minquan,

Are you submitting crash reports? I am not seeing any submitted with your email.

If you want to try improving your experience, let us know.

Thanks,

– Dale

9

I don’t know man might be someone important got me shtting me pants here almost…gulp*

10

If you post the system info from your machine they might help you

Models at those sizes should be no problem for rhino and i have a mid tier laptop running 7gb models with no performance issues.

Choice is yours.

11

I do think Rhino 8 is slower in some situations, or at least acts differently to previous versions when it does hang. That said, I’m not getting stability issues, even on (much) larger files.

If you’re actually interested in triaging the issue, rule out bad geometry causing it with selbadobjects, and (as mentioned) check your blocks. What other programs are you receiving geometry from?

12

Meanwhile, in the shipyard :stuck_out_tongue:

image
image469Ă—249 9.82 KB

14

At first this seemed just in character of your average architect raging about an issue, not even wanting a solution. But, the underlying message they relay is one I could agree on. I noticed too when my files grew to around 2-3 GB (usually due to a combination of working at the urban scale and bad options management, come on I don’t want to create separate files for each iteration), Rhino 8 would really start to chug, so I do understand our professional architect’s frustration.

It’s a real pain to have used worksession files with our team on those projects, as not everyone understood (nor were willing to learn) how it worked, and it ends up creating more headaches for whomever maintaining the project files. It’s a sad reality that people expect Rhino to just work.

I’m happy to provide more information if helpful, but this seems like one of those threads where people just voice out their hope for generalized performance optimizations, there’s no particular area of focus when the program struggles in every way as soon as file sizes grow.