Sketchup performance - Very odd behavior

deadtaco

I have a large section of roadway that I brought into Sketchup Pro 2015 from AutoCAD. The roadway is 3 miles long, and Sketchup ran beautifully after I imported the roadway.

Then I exploded the CAD linework group and performance plummeted. Sketchup is using nearly 100% of one of my processors at all times, and panning/rotating is slow and chunky.

I reselected all of the lines, regrouped them, and boom. Performance is smooth, responsive, and easy to work with. Sketchup is only using 2% processor now.

Why is it that when working in a large model, having it grouped increases performance so much? Is this the case with all models? It seems like an odd scenario to have to group everything just to get a performance boost. I wonder if I should be grouping all of my models if they get too large and chunky. I'll open some other large ones and see what happens.

I assume this is something that can be fixed in a patch, perhaps?

driven

try to follow 50 people at the beach, then try to follow 50 people that are all in a bus, although the bus moves faster and further, the second 'group' are a lot easier to keep track of...
john

pbacot

Really? No one has ever mentioned groups speeding up performance and by so much. But then my model is usually all groups and components--I wouldn't know. I think looking at the AutoCAD import beforehand may show something such as duplicate objects. Another issue is 3 miles is a big model for SketchUp.

hellnbak

@driven said:

try to follow 50 people at the beach, then try to follow 50 people that are all in a bus, although the bus moves faster and further, the second 'group' are a lot easier to keep track of...
john

Nice analogy. You know it's good when even I can understand it (was gonna put a "wink" smilie here but don't like the new styles that are slowly taking over)

deadtaco

The bus analogy is a good one, but incorrect in this instance. When double clicking a group to edit it, it's extremely fast. Why would editing the entities in a group be faster than editing the entities when they are ungrouped? It's the same data either way.

Also, it appears that working on anything with a lot of lines has this same behavior, whether it's 3 miles or 3 feet, so it's not the model's scale that's causing the issue.

I've been doing all of my modelling within the group instead of exploding it since it's so much faster. I think I'll do it this way from now on, even though it doesn't make any sense to me. It seems like some sort of bug, and if Sketchup's performance can be increased by having it fixed, I think it would benefit a lot of people.

EDIT: You can duplicate this behavior by creating a very large, blank Sketchup sandbox with many squares. When it's grouped, it's very fast. When exploded, it's slow. However, without exploding it, you can still enter into the group and make edits and performance doubles. I'd almost swear that it's using raw CPU power to do the rendering in ungrouped objects, and hardware rendering for groups. This would mean it's always best to work ONLY within groups and never do modelling outside of a group if you want to maintain performance. A bit odd!

I just went back to some of my other 3d models that have given me headaches with how slow they performed. I grouped the entire model and now things are running beautifully. Argh!

pbacot

This is odd. Have to check it. I don't explode groups often. That's just asking for trouble in my models. Next thing, geometry will merge or I'll lose something. Also exploding action itself is slow.

deadtaco

I've been messing around quite a bit more with groups and trying to narrow down the issue, and I think I may have figured it out.

Almost all of my models are geo-located with the Sketchup geolocation tool. I'm thinking that maybe the floating point precision and size of coordinate numbers is making the data for each line much larger outside of a group.

For example, a single point at the center of a geo located model may be at the mathematical point of 1401928.01, 278199 in real world coordinates. However, in a group, the center point is at 0,0. This would mean that the lines in a group have much smaller coordinate numbers versus the real world coordinates, so they take less time to calculate.

I'll keep running tests to see if this is the case. If that is the case, then it would be nice if Sketchup could be tweaked so the whole model sees the center point as 0,0, but a simple piece of metadata gives the real world coordinates of that point (I believe this is how AutoCAD does it).

Edit: Clearing the geolocation doesn't have any effect. I'll leave it up to the Sketchup techies to figure it out since I'm out of ideas.

slbaumgartner

@deadtaco said:

Almost all of my models are geo-located with the Sketchup geolocation tool. I'm thinking that maybe the floating point precision and size of coordinate numbers is making the data for each line much larger outside of a group.

For example, a single point at the center of a geo located model may be at the mathematical point of 1401928.01, 278199 in real world coordinates. However, in a group, the center point is at 0,0. This would mean that the lines in a group have much smaller coordinate numbers versus the real world coordinates, so they take less time to calculate.

I don't have an explanation for you problem, but it is extremely unlikely this is the cause. Computers don't take more time to do arithmetic based on the value of the numbers.

tim

@slbaumgartner said:

I don't have an explanation for you problem, but it is extremely unlikely this is the cause. Computers don't take more time to do arithmetic based on the value of the numbers.

Sure they do. Just exceed the integer range of a typical CPU word-size and watch things take longer. Assuming of course you're using a sensible language that can handle arbitrary length integers. If not, it will take a really long time since you'll crash! And no, floating point is not a proper solution in many cases.

slbaumgartner

@tim said:

@slbaumgartner said:

I don't have an explanation for you problem, but it is extremely unlikely this is the cause. Computers don't take more time to do arithmetic based on the value of the numbers.

Sure they do. Just exceed the integer range of a typical CPU word-size and watch things take longer. Assuming of course you're using a sensible language that can handle arbitrary length integers. If not, it will take a really long time since you'll crash! And no, floating point is not a proper solution in many cases.

I was trying to keep it simple. While you are technically correct, your reply is also irrelevant. What makes you think that SketchUp uses any sort of variable-length numeric representations?