Performance issue

My partner and I are working on a submodel which is 1/10th the size of the main model and lately we have both noticed a profound slowness in response by SU. The submodel is about 22MB and the main model is over 300MB.
The slowdown affects both in areas where one would expect, like opening the component browser in detail mode. But it is also affecting simple rotations and moves, but only at first. once the “cache” gets into operation, it becomes fast again, for a while anyway.
We both tried purging unused components and checking our settings, which have not changed.
Both of us have top-of-the-line, or nearly so, iMacs or Windows machines. I have a new iMac with 32GB RAM, and
iMac (Retina 5K, 27-inch, Late 2015)
4 GHz Intel Core i7
AMD Radeon R9 M395X 4096 MB

We are both using the latest SU 2017.

I’ve been able to manipulate my main model fairly quickly as long as I turn off most of the model with layers at a time. But lately something has changed.
I downloaded 2 3D warehouse items - a 3MB outdoor grill and some patio furniture - but checked them for errors in a new file first and found none.

We are at a loss. What is to be done?

file size doesn’t say very much about the content, see “Window > Model Information > Statistics > Entire Model” instead.

1 Like

The sub model has about 1.4 million edges, 560,000 faces and 55,000 components according to Model Info/Statistics. Not sure if these are component definitions or instances.

It doesn’t contain any of the recently added outdoor grill and patio furniture.

But once the file is open, and you try any operation such as orbit, or select, the Mac ‘beachball’ wait icon starts spinning, and SU becomes unusable for minutes. And typing in the browser in this forum sometimes freezes as well, for seconds at a time.

I was trying to select half the submodel at a time to copy and paste into a new model (I’ve done that once into the full submodel) to see if I can isolate the problem to one or other half of the model, and repeat until it starts behaving again.

I’ve JUST ‘got the model back’ in SU after waiting at least five minutes after an orbit command to take effect and finish and now I’ve got the ‘wait’ beachball spinning again for half a minute.

But again, even a single mouse click anywhere in the SU window starts the beachball again, even with nothing selected under the mouse. But Zoom in and out works fluently now.

Just had a thought - could a DC observer be causing this delay? So open Extension Manager window, and start to scroll down to find the Dynamic Components plugin and turn it off. SU freezes again after scrolling a few lines, then unfreezes after half a minute or so, then allows me to turn off the DC plugin.

Will restart SU and reopen the model, to see if that is the issue.

Again, wait icon spins for tens of seconds after saving the model before SU will close…

… and more tens of seconds to reopen SU and the submodel.

So try again turning off ALL plugins.

the ‘Outliner’ tray open can slow down things too…

further infos here.

1 Like

Yes, I know, and it and component browser are both closed.

ensure in “SketchUp > Preferences > OpenGL” not to use an AA more than 4x and try if disabling an activated “Use max. Texture Size” helps… at least if not required (during modeling).

I’ve finally, with a lot of waiting, selected about half of the building floors in the model, cut them to clipboard.

I’m (again with a long wait) pasting them into a new model, which took about a minute. And Saving that half of the submodel is also taking a minute or more.

Half an hour later, I’ve split the model into its constituent levels.

Will investigate later whether any individual level is problematic - have to stop now for a while.

We have recently seen users with memory leaks on high sierra, memory usage out of range,
Have you checked the task manager?

We are both still on Sierra, not High Sierra.

I’m still not that familiar with Macs. Where’s the Task Manager? Isn’t that Windows?

On my phone, maybe called utilty manager on mac
Edit : activity manager

Found Activity Manager using Launcher - thanks.

Will try to see what’s happening with the aid of that, when the model freezes.

Well, I’ve checked that each separate level saved into a new file, opens quickly (3-4sec) and has no problem orbiting, zooming, opening any number of levels of components for editing (almost instant per level), changing from Camera/Parllel projection ot Perspective or vice versa, or saving (9 or 10 secs per file).

I opened all of the levels at once in SU, then opened each window in turn starting from the highest numbered level (64). I then selected all, then pasted in place into a new drawing - copy was almost instant, and paste took about 6 seconds for beach ball to stop, then another 3-4 sec to display in the new file. Saved the growing file after each addition of another level - around 9 sec for the first level only, slowly growing to around 20 sec when half done.

Tried opening component browser, but that WAS slow … over a minute before I got tired waiting and switched to starting this post. But it had finished when I looked back, and the model takes about 10 sec to display when switching windows in SU.

Carrying on adding levels…

Things ARE slowing down, but steadily, not erratically. Changing a component’s name in Entity Info, for example, with the Component Browser now closed again, takes several seconds, but it is almost instant to select and display another Entity Info window for a component.

Pasting another layer in place is slowing down a little - 6 secs to stop beachball, and another 10 sec now to display it but still not running away in timing, just a slow increase.

Adding Level 55 seemed to mark a bigger slowdown, but still not excessive - paste time up to about 25 sec in total.

Switching back from Chrome browser window in the forum to the SU window with the growing model is now taking longer, but still only about 20sec.

With only two levels to go, orbiting is getting very slow again, and something is interfering with typing this post - the text display stutters behind my typing.

And switching between this forum window, or between SU windows, is getting slower to - around 25 sec now. And everything else is slowing down too.

As the levels are symmetrical and mirrored, I’m starting to try to delete one half of each level, without losing anything that’s in only one half of the whole level (there are inconsistencies, so I have to be careful).

That’s going very slowly, and getting slower.

Watching the Activity Monitor, I can see that SU is maxing out the CPU, not as I thought probable, writing to disk.

CPU usage for SU is getting over 100% (100.2% !!) with almost all other processes each accounting for much less than 1% each, except for a couple of others at around 2-3%.

Memory usage is well below half of the installed memory.

The Kernel Task is using a steady 2-2.5GB, SU just below 2GB.

EVERYTHING in SU is now getting VERY slow again. I’m going to have to split the model in half, re-enable Plugins, and restart SU.

I’ll then split each half of the Levels into N and S halves, checking I’m not losing anything, once I have the Mirror plugin back in operation - it’s too tedious to copy and flip, or Scale x -1.

I’ve been digging a bit into the statistics of this problem model, and another one with mostly similar statistics that is behaving more normally. The model on the left has a file size of 22MB, the one on the right is almost twice the size, at just over 43MB.

Here’s a comparison, with the problem model on the left.

The only substantial difference I can see is that the problem model has almost four times as many images - and I think I know what they are.

Once I can get the component browser in Levels F50-64 to open (it’s taken many minutes already*) I’ll try and delete what I think are the problem images, and see if that impacts the performance favourably.

In the meantime, I have a workaround in the two half-submodels, which on their own one at a time are ok. I can paste one at a time into the Arch 24 to use for registering new components against.

  • Activity monitor shows that SU has been running at 95%+ CPU load for over a quarter of an hour, since opening the Levels 50-64 submodel.

I’ve deleted the components with images (saving 4MB in file size), and also turned off layers with high edge counts from railings.

Moral: the railings should be on a layer of their own, so they can be turned off for normal modelling, and only turned on for viewing. And I’ve made a low poly version that uses a small image for a texture, containingg one railing and a transparent space between railings, which is a much ‘lighter’ component than the existing DCs. And the image should be reduced sharply in size, and also put on a separate layer to turn off when not needed.

The submodel performance has been transformed. Neither change alone was enough, but the combination has worked well.

Although the Arch 24 submodel has some of the same images (though fewer of them) they were on layers turned off, so didn’t affect performance much.

Hmm, it looks like the railings will have to be replaced, or at least turned off most of the time. I actually did this for the sub-apartments levels F01-F03 with an “Outer Railings and Ramps” layer for each level, but I didn’t continue it for the higher levels from F04 up, thinking turning off the floors the railings were in was enough.

It seems the floors may need reworking anyway, to fit better with the new plaza walls. This might be the time to redo the terraces with component stringer and include the reduced impact railings in them instead of the overall floor, and plot them with component stringer too. I believe when I was looking at the component browser’s details I saw a railing with over 7,000 edges alone, so that could be a major issue if accumulated. Low walls around all the terraces would have been a lot simpler and easier to create, but would have meant a more uniform appearance without differentiation on the terraces so easily observable. Also, a thicker wall vs. a thin metal railing.

I’m still a bit surprised it is such an issue, particularly in a much smaller model, since I just went through levels F49-F75, fixing the inner courtyard separator walls which are perpendicular to the F34 - Mid-courtyard apartments wall (see below about renaming this), which meant turning on all those floors including railings and I had no real difficulties other than momentary video lags. Of course, I went through your levels to do that too, but I was working on the floors only. I can re-export those for you if you haven’t already worked on them, or else re-replace the separator walls into your submodel before I import it into the main model.
The inner courtyard terraces on the outer side were a mess and had to be worked on as part of the whole, including renaming the F3 - Mid-courtyard apartments wall to F34 - Mid-courtyard apartments wall, which reflects the level it actually started on. I can make this change to your submodel too unless you can do it.

As you can see, it is quite difficult NOT to work on the levels overall when fixing things, so I hope your submodel work will not take too long.

But I will try to focus on the higher levels today. I’m on F76 floor now and should be able to knock that off pretty quickly and then make further adjustments to the edge apts. on F77, then go up again from there.

Anyway, continue what you’re doing, but realize that the plaza terraces, at least, will all have to be redone not just for the railings, but for size and position relative to the plaza walls and the adjusted floors behind them, done by either you or me.

End of night shift.

switching off eye candy (shadow, transparency, x-ray) and using a simple style during modelling is evident. Ensuring that the model is near the model space origin is - especially after a DXF/DWG import w/ option “Preserve Drawing Origin” enabled - not always obvious.

We’re doing that already, but it is always useful to remember to do it while modelling.

No DWG imports here, and the model is already close to the origin - though it is big in human terms, it starts ON the SU World origin, and the extremities are only about 1000’ away.

When working with large models, I try to keep the hierarchy as simple as possible. A large list of unique component definitions, materials, layers seem to take a lot more time in SketchUp, when opening the component browser for instance, compared to a much smaller list.

I try to merge (explode) things, to keep the number of unique elements down (component definitions, groups, materials, layers). For instance;

  • Imagine a restaurant with 100 tables where each table has 4 chairs.
  • The table could be a component, the chairs as well. You could go even further (seen before in the 3dWarehouse) and split up the chair and table into 2 mirrored halves as well adding more unique components to the definition list;
  • the number of unique components in this case would be; 1 for the complete table, 1 for just a mirrored half. Same for the chairs. Total = 4.
  • An alternative would be to just explode the table and 4 chairs into 1 component (and maybe keep the above structure in a separate file in case you need to alter the table/chair at some point). Total = 1

The difference in unique components for a fully furnished restaurant could be huge.The same logic can also be applied to the layers and materials.
I always try to ask myself; does this really need to be unique or can it be exploded/merged, can an existing material / layer be re-used?

Not sure if its related but maybe this could help.

It is certainly relevant. It’s a point that I hadn’t really taken on board fully, though in a few cases I have been doing what you suggest but more as a side effect of reducing edge and face counts, not aiming at the component counts.

I like using components to keep things separate, organized and editable, so there’s a deep level of nesting in some places, and once we have the shape finalised, some of the levels could indeed be exploded.

For some components like Dynamic Component railings with many many instances of the vertical spindles (which pushes the edge count WAY up), I have worked to simplify them. Haven’t yet had time to replace all of the original DCs though. (I plan a separate post about that soon).

And in some other cases like furniture and bathrooms I’ve worked hard to simplify grossly over-detailed 3D warehouse models. But mainly aiming to reduce edge and face count, not the number of component definitions, though that has happened to some extent as a side effect (see Simplifying 3Dwarehouse models for use as entourage.

But I have not systematically thought about exploding other sorts of components with multiple levels of nesting, to reduce the overall number of component definitions and instances, which is very large even in some sub-models, let alone the full building model.

I’ll give that further thought and analysis.

Thank you very much for the comments - they are definitely useful food for thought and action.

As has been said, over nesting slows SU.

How do I make SketchUp run faster? — See the SketchUp Sage Site