Performancies issue

Orionis98

Hi, as said in a previous post, I'm a newbie in dynamic components.
Step by step I am learning something using a Kitchen scene to make pratice.
With just a couple of DCs I did not notice that my PC response was slow, until I reach a 'complexity' of around a dozen among main and sub-components.

Components have some material and sizing attributes and some parts can be hide depending on selected states (I suspect this is the trouble).
Now, to update a component with a new attribute's value it takes between 3 upto 5 seconds.

It is 'expected' or 'slow'?

This is my main configuration:
CPU: Pentium Dual-Core G320 @ 3GHz
RAM: 4GB
Video: GeForce GT730
Windows 7 SP1 32bit
SU 2016

I undestand this is not the optimal configuration, even if few years ago it was, but this is what I can afford right now.

The interesting point is that with a normal scene without any DC, even complex and with hundreds of elements, I do not see any visible slowing down in orbiting, zooming, scaling...

Should be an expected behaviour with my config I think it would be better to forget about DCs.

pcmoor

Can you share some of of your components? Maybe private if intellectual property. Stray errors can significantly slow DCs down, they can be caused via copies of subs for a new component without making each part unique.

Orionis98

@pcmoor said:

Can you share some of of your components? Maybe private if intellectual property. Stray errors can significantly slow DCs down, they can be caused via copies of subs for a new component without making each part unique.

Let me clean up a little my file and I will be happy to share it.

In the meantime, your sentence ('copies of subs for a new component without making each part unique') make me think about a possible mine misunderstanding of how a DC must be used.

Actually I have 3 copies of the same component, a kitchen cabinet with different formats (4 drawers, 2 drawers, plain panel,...); the format is selects by a 'Type' attribute and the unwanted parts are hidden. The same for the sub-components materials, which can be 'local' or 'global' depending on another flag.
The 3 copies are NOTunique; I did not think this is a requirement.
Is it wrong?

Giacomo

pcmoor

Just to be clear, copying is not the issue, but using a copy to create a new component is. This is very much the case if a copy or instance is used in another file, isolated, changed then brought back within the influence the original.

Copies of subcomponents can cause problems if they not not made unique, even groups can retain a connection when copied. You change the formula in one sub, it effects all the others that are copies. Move a component into another file, change the formulas, call it something else, bring it back into the orginal file, the subs will "update" to the new formulas, usually the affected components will have red # errors
Reuse or repurpose is okay, but make each sub component unique within a master file, unless the sub is to be used by all (like a shelf,door) then the parent! reference is used rather than the parents attribute dialog heading otherwise cupboard1!doorwidth will overwrite cupboard2!doorwidth whereas parent!doorwith works for both

Orionis98

@pcmoor said:

Just to be clear, copying is not the issue, but using a copy to create a new component is. This is very much the case if a copy or instance is used in another file, isolated, changed then brought back within the influence the original.

Copies of subcomponents can cause problems if they not not made unique, even groups can retain a connection when copied. You change the formula in one sub, it effects all the others that are copies. Move a component into another file, change the formulas, call it something else, bring it back into the orginal file, the subs will "update" to the new formulas, usually the affected components will have red # errors
Reuse or repurpose is okay, but make each sub component unique within a master file, unless the sub is to be used by all (like a shelf,door) then the parent! reference is used rather than the parents attribute dialog heading otherwise cupboard1!doorwidth will overwrite cupboard2!doorwidth whereas parent!doorwith works for both

Fantastic!
Inheritance and Incapsulation: I should have thought to them.
I made a quick and dirty test and I am pretty sure that was the problem.
From now on I will follow your guidelines, thanks so much.

DavidHinson

I am having more dramatic performance issues and I am sure that your suggestion of copies is the solution. In order to fix problems more quickly, is there a way to change multiple attributes on a component before Sketchup updates the drawing? Sometimes when two attributes depend on each other, the results of changing only one attribute gets me in trouble, even locking my system.

pcmoor

Not quite sure what is the problem, you could private message some examples; however some points

Breaking a bond is done by making the copied components unique. for groups, sometimes make unique (right click menu) is available.
If groups are the problem then running this script should help

http://ruby.sketchup.com/Sketchup/Group.html#make_unique-instance_method

If the copied groups or components have the same parent, same header then double click the title box to change its name before changing the attributes