- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
Hi @maxim.teleguz. Just as a test, and for the fun of it, I decided to test the performance of two iLogic rules within the same document that are both given the same exact task. Both rules will first check to see if an iProperty exists, then create it if it did not exist yet. Each time they are ran, I ensure that the iProperty does not already exist, before running it.
The one rule is using the 'shortest' or least amount of code possible, by using the iLogic only snippet 'iProperties.Value()', and uses a Try...Catch block to avoid the expected error.
Try
i = iProperties.Value("Custom", "1")
Catch
iProperties.Value("Custom", "1") = 1
End Try
The other rule is using only Inventor API code (no iLogic only snippets) and the traditional routine of using a 'For Each' loop and 'If...Then' statements to find the existing property, and then create the property if it is not found.
oCProps = ThisApplication.ActiveDocument.PropertySets.Item("Inventor User Defined Properties")
Dim oMyCProp As Inventor.Property = Nothing
If oCProps.Count > 0 Then
For Each oCProp As Inventor.Property In oCProps
If oCProp.Name = "1" Then
oMyCProp = oCProp
Exit For
End If
Next
End If
If IsNothing(oMyCProp) Then
oMyCProp = oCProps.Add(1, "1")
End If
I used a code based stopwatch to monitor the time it took for each to perform its task, then ran each rule multiple times to compare performance. Three typical finishing times for the first rule (the short one) were: 0.07 seconds, 0.091 seconds, and 0.065 seconds. Three typical finishing times for the second rule (the longer one) were: 0.008 seconds, 0.015 seconds, and 0.013 seconds. It was pretty clear that the longer, more proper API code rule won out over the coder's shortcut rule in performance, just as I attempted to explain before. There may not be much difference when only working with a single property in a single, simple part document, but when your code is working through 10's of properties in each referenced document within all levels of a large complex assembly, this bit of code may be used many hundreds of times (if not thousands), and the difference in performance will definitely be appreciated, or even needed.
What some folks may knot realize is that there is a larger routine block of code that gets ran in the background to process the request every time you use the iProperties.Value() snippet. And in more complex situations, it is not always very clear which document it will be acting upon, even when using the provided means to specify which one you want it to act upon. The Try...Catch statement is definitely a great tool for handling expected errors, and has been a basic component of the vb.net system for a long time. I use it quite often throughout my automation solutions, when there is no other way to avoid an expected error. But in cases where there is another way to avoid that expected error, the other way is often going to perform better, even if it may take a bit more code.
Wesley Crihfield
(Not an Autodesk Employee)