Mass suppression/unsuppression taking extremely long

[relicseekerharry]

I have a guide bar part with up to 100 lanes, each with the features lane extrusion (cut), a chamfer (named tilt) for its top and bottom and a shared fillet for each half of the lanes (1-50 and 52-100). Lane 51 is special as sometimes its suppression state depends on whether there are an odd or even number of lanes. The attached code looks at what lanes are to be included and then either suppresses or unsuppresses them based on this metric. However, suppressing from 100 down to 40 took almost half an hour, and unsuppressing back to 100 took about 20 minutes. Suppressing a given lane suppresses its chamfers as well. Does suppressing the chamfers explicitly despite this make it take longer to run? 

Is there anything else I'm missing, or is it just the sheer volume causing the long time?

Dim functionalChains As Integer = Chains
Dim realMode As String = Mode
Dim notMode As String

If Mode = "Infeed" Then
	notMode = "Discharge"
Else
	notMode = "Infeed"
End If

Parameter.UpdateAfterChange = True
iLogicVb.UpdateWhenDone = True

If Chains Mod 2 = 0 Then
	' first lane either side of middle has pitch/2 from middle to make pitch normal there
	Parameter("InfeedPMod") = InfeedPitch / 2
	Parameter("DischargePMod") = DischargePitch / 2
	
Else
	' no pitch difference here and overlapped lane will be eliminated so middle lane is directly in middle for odd number of lanes
	' functional chains +1 as lane 50 and 100 will still be outermost even if 99 chains selected as middle lane 51 is not there
	Parameter("InfeedPMod") = 0
	Parameter("DischargePMod") = 0
	functionalChains += 1
	
End If

' loop through all lanes and disable/enable if lane falls into scope of chains number
Dim i As Integer
For i = 1 To 100 Step 1
	
	If i <= 50 And i > (functionalChains / 2) Then
		
		Feature.IsActive(realMode & " Bottom Tilt Lane " & i) = False
		Feature.IsActive(realMode & " Top Tilt Lane " & i) = False		
		Feature.IsActive("Lane " & i) = False
		
	Else If i > 50 And i-50 > functionalChains/2
		
		Feature.IsActive(realMode & " Bottom Tilt Lane " & i) = False
		Feature.IsActive(realMode & " Top Tilt Lane " & i) = False		
		Feature.IsActive("Lane " & i) = False
		
	Else
		
		Feature.IsActive(realMode & " Bottom Tilt Lane " & i) = True
		Feature.IsActive(realMode & " Top Tilt Lane " & i) = True		
		Feature.IsActive("Lane " & i) = True

	End If
	
Next i

' lane 51 doesn't exist if odd number of lanes (as 1 and 51 placed on top of each other)
If Chains Mod 2 = 1 Then
	Feature.IsActive(realMode & " Bottom Tilt Lane 51") = False
	Feature.IsActive(realMode & " Top Tilt Lane 51") = False
	Feature.IsActive(realMode & " Lane 51 Fillet") = False
	Feature.IsActive("Lane 51") = False
Else
	Feature.IsActive(realMode & " Bottom Tilt Lane 51") = True
	Feature.IsActive(realMode & " Top Tilt Lane 51") = True
	Feature.IsActive(realMode & " Lane 51 Fillet") = True
	Feature.IsActive("Lane 51") = True
End If

Try
	Feature.IsActive(realMode & " M6 Side Hole") = True
	Feature.IsActive(realMode & " Side Hole Mirror") = True
	Feature.IsActive(notMode & " Side Hole Mirror") = False
	Feature.IsActive(notMode & " M6 Side Hole") = False
Catch
End Try

[WCrihfield · Accepted solution]

Hi @relicseekerharry.  Since I am not familiar enough with your designs or how your system is set-up, it would be very difficult to accurately predict the best way to manage this specific situation for best performance, but I do have something to share that might help some.  The code snippets you are using (Parameter( ) & Feature.IsActive()) are unique to the iLogic API, and meant to help simplify coding, so there is not much we can do about how they perform.  But there are Inventor API alternative ways of doing those things, which may be a bit more beneficial.  For example, getting a PartFeature Inventor API object, then setting its PartFeature.Suppressed property (Read/Write Boolean) value, does essentially the same thing as the 'Feature.IsActive' iLogic shortcut, but wants us to start from the actual feature object, not just specify the name of the feature.  That one is not too advantageous sounding in this context, but other related methods are.  I'm talking about the PartComponentDefinition.SuppressFeatures method, and the PartComponentDefinition.UnsuppressFeatures method.  These two methods allow us to supply them with an ObjectCollection filled with multiple PartFeature objects, then it usually suppresses or un-suppresses that group of features much faster than doing so individually.  But using them may require more code, because you have to actually dig down to each feature through Inventor's API object model to obtain them, instead of just specifying their names directly.  When using the iLogic 'shortcut' route to suppress or un-suppress a feature, an additional block of code gets ran in the background that:  must first determine which Document that it should be effecting and get a reference to it, then it must dig down through its component definition, then to its features, then 'find' the feature that is named what you specified, and is most likely doing all that using Inventor API code.  Then it can actually suppress or un-suppress that feature.  If doing things the Inventor API way directly, you would get references to all those objects first (once), then would not have to 'find' all of it again again each time.  But the actual difference in performance between the two ways of doing things would need to be tested to see if it would be enough of a benefit to be worth all the extra code and complexity.

Another factor may be what I'm seeing in the first two lines of code, where the terms "Chains" & "Mode" are being used.  I assume those are the unquoted names of local Parameters within the same Document that this 'internal' iLogic rule is saved.  If so, their presence is likely causing that rule to get triggered to run every time their value changes.  If their values get set or changed often (or multiple times per single manual action), that may be causing more processing than may be needed.  Especially if this rule is also triggered to run automatically by other events/settings within the iLogic 'Event Triggers' dialog.

[relicseekerharry]

Hello, and thank you for your detailed response. This is from a rule in a part in a larger configurator. 'Chains' and 'Mode' are set externally as they drive geometry for the part. The rule should only be running once as it is suppressed, has no event triggers, and its only mention is in a rule in the assembly this part is a subassembly of. 

I'll have a tinker with the API suppression method and see if it increases performance!