7.1 Performance

thomthom

Long save times - SU files can get fairly large and I've had autosaves taking 1min+ each pop for large architectural models. Again, I'm comparing this to other programs such as 3ds Max and AutoCad.

100+!!!

@unknownuser said:

UV mapping is a huge bottleneck for me and for many others. It requires going to another program to do any UV mapping other than planer or box (unwrap, cylindrical, sphere, etc.).

+++

Whaat

Great job on 7.1!

In terms of increasing performance further, these are my wishes:

Improve the speed of saving and loading large SKP files. Try opening a SKP that was exported from Microstation. From my experience, a 40MB file can take more than 3 minutes to open and save. It might have something to do with how Microstation creates deeply nested groups when it exports a SKP file.
Improve the speed of geometry creation. This is a huge bottleneck for Ruby scripts. Why does it take so long in SketchUp compared to other apps? It also takes a very long time to import high-poly 3DS meshes due to this same problem.

thomthom

@whaat said:

Improve the speed of geometry creation. This is a huge bottleneck for Ruby scripts. Why does it take so long in SketchUp compared to other apps? It also takes a very long time to import high-poly 3DS meshes due to this same problem.

Yes! Good point! Ruby geometry creation is a big bottleneck. I was doing some testing and found that most of the time in my scripts is spent on the methods that create geometry. All other calculations become insignificant. I found that entities.fill_from_mesh is the fastest way to add geometry, but that isn't always an option to use. And another observation is that the more entities is already in the entities collection, the longer the methods to create geoemtry take. Doesn't even take that much geoemtry before it starts to bog down.

brodie

I have to agree with Whaat regarding the rubies. Rubies, in general, are problematic. With no integrated progress bar, screens going blank, and some rubies taking 5min-5hours to do there thing it feels extremely clunky and has caused me to do a lot of things the hard way just to avoid problems.

-Brodie

thomthom

In regard to Ruby and adding geometry: Check out this thread for comparisons of various methods to add geoemtry - and the general frustration of the topic: http://forums.sketchucation.com/viewtopic.php?f=180&t=23994

chrisjk

Please, please, make SU capable of using all my CPU cores!

AndrewS

@chrisjk said:

Please, please, make SU capable of using all my CPU cores!

What specific operations do you believe would be best served by adding multi-core utilization? 3D is an inherently GPU-heavy endeavor and most real-time editing, orbiting, etc., can't really be improved with extra CPU cores. There are some areas where multi-core strategies can be applied; I'm just curious what items stand out in your mind.

Andrew

thomthom

Don't have anything to add regarding CPU cores, but it made me remember another issue ruby scripters have been trying to deal with: being able to create new threads. It seems to be impossible within the SU Ruby environment.
Many attempts has been made in order to allow CPU intensive scripts work without locking up the SU UI.

Whenever a processing heavy script runs and you switch to another window while it works the SU window will grey out and stop updating, and from testing - that also seem to cause the script to run slower, impacting the total processing time.

Tyler Miller

Thanks everyone for your replies. I'm thrilled the 7.1 performance boost is working out for most of you.

We'll continue to spend a large portion of our time dedicated to performance improvements. We have not hit a ceiling as of yet, and as many of you point out, when you remove one bottleneck, it often unmasks the next bottleneck.

One thing to note, SketchUp has a very unique geometry engine that requires us to merge any new geometry in will all the other geometry in the same component. This is part of what makes the SketchUp magic possible, but it can cause as slow-down when adding any significant amount of new geometry, or even a small amount of new geometry into a component with a lot of existing geometry. Importing, or using a Ruby script that is creating geometry makes this issue really noticeable. We'll continue to look for ways to optimize this area.

Thanks again,
Tyler
Google

thomthom

@tyler miller said:

One thing to note, SketchUp has a very unique geometry engine that requires us to merge any new geometry in will all the other geometry in the same component. This is part of what makes the SketchUp magic possible, but it can cause as slow-down when adding any significant amount of new geometry, or even a small amount of new geometry into a component with a lot of existing geometry. Importing, or using a Ruby script that is creating geometry makes this issue really noticeable. We'll continue to look for ways to optimize this area.

Is it not possible to prevent SU from doing all this magic when you want to add a large amount of geometry? Is it something that has to run every time you add something? Would be nice to be able to just dump a pile of geometry into a model, without needing SU to do "magic".

Explode is also a method that really bogs down. On larger models it practically impossible to use as it just grinds SU to an halt. I often don't need SU to merge everything - being able to quickly explode would be a great performance improvement. I expect explode's slowness is related to the slowness of adding geometry in general.

ken

Well, I have noticed that when I add another toolbar, and the toolbar scatter all over the screen, replacing the toolbars is a lot easier and more consistent. I don't seem to have to chase a toolbar all over the screen to get it to look in position or have a toolbar that refuses to be located where I want it. To me this is an improvement from the hours of chasing toolbars and accepting a placement I really didn't want.

Ken

solo

What I would really like is if there was a way SU could recognise imported groups from other apps that are identical and make them into either identical components or groups with the same attributes that groups and components in SU have, IE edit on and all change and smaller foot print in SU.

I do a lot of work with clients that send me .3ds, .obj, etc models with say 200 columns (identical) and I need to spend hours deleting all but one, making it a component and duplicating and placing one by one.

chrisjk

@andrews said:

@chrisjk said:

Please, please, make SU capable of using all my CPU cores!

What specific operations do you believe would be best served by adding multi-core utilization? 3D is an inherently GPU-heavy endeavor and most real-time editing, orbiting, etc., can't really be improved with extra CPU cores. There are some areas where multi-core strategies can be applied; I'm just curious what items stand out in your mind.

Andrew

Andrew,

I notice it in the Rubies thing discussed above but not being a Ruby developer, I confess I do not know if it’s a CPU or a GPU bottleneck.

chrisjk

I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it. I don't always remember to do this at the time of creating the geometry and it's irritating to have to go back and fix something where a face hasn't been created etc.

I apologise if this isn't considered a performance issue.

Gaieus

@solo said:

What I would really like is if there was a way SU could recognise imported groups from other apps that are identical and make them into either identical components or groups with the same attributes that groups and components in SU have, IE edit on and all change and smaller foot print in SU...

Can't you do this with imported stuff?

(And sorry for the OT post - we can chop these parts off)

solo

Sure one can do that, but they are just grouped or made into a component, I need to make them so that if I alter or texture one, it will edit all the others accordingly.

This is a performance issue as if indeed they all act like one component duplicated 200 times instead of 200 separate objects, SU either crawls or flies.

Gaieus

Well, in my above example, I made the three groups instances of the same component - certainly however SU keeps track of "instances" of the same group, too.

mitcorb

@chrisjk said:

I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....

I apologise if this isn't considered a performance issue.

I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.

Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorb

Whaat

@mitcorb said:

@chrisjk said:

I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....

I apologise if this isn't considered a performance issue.

I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.

Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorb

+1

thomthom

++