ASSEMBLY PERFORMANCE: Poisoned Assembly

I have an assembly that:

1. Will rebuild in under 2 minutes.
2. Seems normal in all other respects
3. Can take up to 2hours 30 minutes to save.

This isn't a network issue, I have gigabit and bandwidth isn't being
used
The CPU is running 100% for the whole time during the save punctuated
by blips of network access.

I figure something has "poisoned" the assembly. Any thoughts or
questions (even the obvious) on what to look at would be appreciated.

TOP

 

any patterns?

 

Yup, 3.

I know, they have to go. Add external references too. But, why at save
and not on a CTRL-Q rebuild?

 

Additional information. This is the journal file from the time I
selected the assembly till after the save. Notice that save is not
logged. It is like it hasn't started saving yet. The selectby just
keeps repeating over and over.

swApp.ActiveDoc.ActiveView.FrameLeft = 0
swApp.ActiveDoc.ActiveView.FrameTop = 0
swApp.ActiveDoc.ActiveView.FrameState = 1
Set Part = swApp.ActivateDoc2 ("400459.SLDASM", False, longstatus)
swApp.SetUserPreferenceToggle 119, 0
swApp.SetUserPreferenceToggle 119, 1
swApp.SetUserPreferenceToggle 119, 0
swApp.SetUserPreferenceToggle 119, 1
swApp.SetUserPreferenceToggle 119, 0
swApp.SetUserPreferenceToggle 119, 1
swApp.SetUserPreferenceToggle 119, 0
swApp.SetUserPreferenceToggle 119, 1
swApp.SetUserPreferenceToggle 119, 0
swApp.SetUserPreferenceToggle 119, 1
' MSGBOX
' 400459 - Rebuild Errors

' MSGBOX
' Warning: 400522 has rebuild errors

' 401901 has rebuild errors

' Coincident171: Warning: One of the entities of this mate is
suppressed, invalid, or no longer present.


Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050064-1@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050064-1@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-64@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-64@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-65@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-65@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-66@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-66@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-67@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-67@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-68@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-68@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-69@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-69@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-70@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-70@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-71@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True
boolstatus = Part.Extension.SelectByID2("050047-71@400459",
"COMPONENT", 0, 0, 0, False, 0, Nothing, 0)
Part.ClearSelection2 True

 

Mark,

Think you put your finger on it. If you look at the journal file it
keeps repeating a select on 0500064. That is one of the patterened
assemblies. As soon as this sucker completes I will put those items
into a subassembly all of their own and get it out of the top level
assembly. That will be the first step.

Thanks.

TOP

 

How many parts? If parts change and regenerate, then they will need
to save, also.

I have my options set such that references open read-only. I have a
"Save Silent" macro that skips saving parts that are opened read-
only. This has reduced save time.

 

TOP: Swks 2007?

 

So am I reading this correctly that component patterns in assemblies
increase the save time (not just this file, but in general)? I have
not heard this before, and we have lots of patterns and long save
times. Any specific kinds of patterns -- feature driven vs linear,
component vs subassembly? Thanks!

Eric

 

Flexible Sub assemblies? I haven't used them since SW2005 when they were
the apparent cause of much angst in a couple of my large assemblies,
move one part the whole assy. flew apart.

 

for some strange reasons it looks like sw2007 doesn't like pattern at
assembly, either parts pattern and most futures patterns.
in sw2006 assemblies with patterns were slow but in sw2007 is much
much worse.I do not know why and it is just my observation
Mark

 

To all who helped. Thanks.

The last save before reading responses here took upwards of three
hours. Thanks to the input here and on Dan Bovinich's email list we
are down to 2 minutes. Pretty good results.

After hearing the pattern problems and looking at the journal and
seeing it stuck on a patterned part that was the first thing I fixed.
To do that I pushed patterned stuff down into a sub assembly and this
by coincidence also removed some in context that probably also wasn't
helping much. After a couple of crashes everything was just fine.

I just might want to look into the Tick's macro too.

Next I'll be changing nappies.

TOP

 

So do you think it was the patterns or something extraneous like the
in-context stuff? We do lots of component patterns and I don't recall ever
seeing saves more than maybe a couple minutes.

WT

 

Wayne,

If you look at the journal file it kept coming back to the same part,
different instance. I dissolved the patterns and pushed them down into
subs. When I did that if just kept getting faster. That process also
broke some external references. So I can't say which was worse. This
particular person also was in the habit of mating to patterns. Big no
no there too.

I didn't have the time to check the effect of each move. At
potentially 2-3hours per test that wasn't practical. I'll grant you
this wasn't everyday behaviour, but when it happens, ouch.

TOP

 

Does this produce better save performance than the "Don't prompt to save
read-only referenced documents" system setting? I'm sure you're aware of
the setting, but I'm not sure how the macro might be different.

 

Since the pattern now exists in a subassembly, can we conclude that there
was a problem with that particular pattern, instead of component patterns
in general? I don't want to hear later of CAD admins banning component
patterns.

 

Dale,

This one was complex so I would not make a generalization. Patterns
will of course slow an assembly just like anything else. And with
patterns there is the danger of making a mate to a patterned item
which will cause a bigger hit. Ditto with in-context to a patterned
item. For that reason when I mate, I do it rolled back to the mate
tree. Then doing no-no's is less likely.

I will also dissolve patterns if and when they are causing a problem
with performance and it can be done without causing other problems. I
place the dissolved components in a folder so I can delete and
recreate it as necessary.

BUT, the problem I had was with saving; it was orders of magnitude
slower than it should have been, and it could have been patterns, in-
context or a combination of them peculiar to this file. Ordinarily
patterns don't cause the kind of major problem I was seeing.

TOP

 

Paul,

Did you check on settings such as saving the mass prop data with the
parts or saving tessellation data with the parts? These would both cause
saving to be much slower than simply rebuilding.

 

Matt,

True enough and thanks, but getting the patterns out of the top level
and breaking some of the in context stuff made the huge difference.
I'll check on this as soon as SW stops crunching in a few hours (on a
test, not a real part).

will assume means off.
There are several tessalation settings there and I am not sure which
correspond to the options you mentioned.


TOP

 

Sorry about your save issue. That is a drag, but I suppose you're
email Inbox is pretty clean due to the extra time

However, this DOES bring up another can o' worms that I have hesitated
to talk about for years.

Errr... does Ctrl+Q on the assembly level actually DO anything?

Whenever I do one, it is lightning fast, like nothing happened.
Forget about the number of in-context references (a few to a relative
gajillion - no difference in rebuild time that I recall), and forget
about the number of top-level mates. Every time I ctrl+Q an assembly,
it is over in about a second regardless of the assembly. However,
switching back from editing a part in the asm at the part level and
returining to the asm (even if choosing NOT to rebuild the asm, which
I almost always do) it can take minutes.

So my question is, has anyone seen a ctrl+Q of an assembly take a non-
trivial amount of time, which we would expect if there was a non-
trivial amount of assembly detail being calculated? (caveat - I never
do assembly cuts except for animations, and rarely do joins or
cavities, so I am missing data on these features)

For release, I would love to have a single key combination that forced
the rebuild of everything in the asm, even if I had to wait to save it
the following morning. i know some folks who assume that a ctrl+Q of
the assembly verifies everything, but I know that is not the case. I
learned years ago the dissapointment that to check for release I have
to methodically open and Ctrl + Q every single component because a top-
level asm Ctrl+Q doesn't seem to do much of anything.

Anyone know what is really going on? Anyone else have a different
experience that might shed some light on this?
Ed

 

NOTHING: edit part, change a dim, Ctrl+Q: nothing changes. Hit 'trafic
light': geometry updates. (SW06-5.1)
WTF?