iProperty Performance

Here’s some performance data regarding using Inventor and Apprentice to work with iProperties.  I found this interesting and think it will be useful when architecting your programs so you fully understand the advantages and disadvantages of different approaches.

All of the test results shown below are for processing 1000 unique files.

Test 1 – Open, Edit, Save, Close
This test opened each of the 1000 files, edited the value of two iProperties, saved the document, and closed it.

1. Apprentice – 116 seconds.
2. Inventor (visible document) – 1068 seconds.  This test opened the documents visibly by setting the second argument of the Documents.Open method to True.
3. Inventor (invisible document) – 238 seconds.  This is the same as the test above but opens the documents invisibly by setting the second argument of the Documents.Open method to False.

The biggest difference is between opening the document visibly or invisibly.  When a document is opened invisibly, Inventor is able to optimize the open and not read all of the file.  Opening a file invisibly is similar to the time it takes in Apprentice, as shown by test 2 below.  However, for test 1 Apprentice is still twice as fast.  Two things account for the extra time spent by Inventor; changing the property value and saving the document.  Changing the value of an iProperty in Inventor is transacted, meaning that you can undo the operation.  Transacting has some overhead which accounts for some of the time.  Apprentice doesn’t have any transaction capabilities so it doesn’t have this overhead.  The other big difference is the save.  To save an iProperty change in Inventor you need to save the entire document using Document.Save.  In Apprentice you can save just the iProperty portion of the document using PropertySets.FlushToFile.

Test 2 – Open, Read, Close
This test also operated on all 1000 files by opening a file, reading property values, and closing the document.

1. Apprentice – 92.341 seconds
2. Inventor (invisible document) – 100.374 seconds

These numbers show that there isn’t a lot of difference between invisible Inventor and Apprentice when you don’t do anything that’s transacted and you don’t save the document.  This is particularly important for add-in writers to understand since you can’t use Apprentice within an add-in.

Test 3 – Open, Close
This test uses VB.Net to open and close the same 1000 files.  It opens a file, reads the file into memory, and closes the file.  It is a pure VB.Net program and has nothing to do with Inventor.  I wrote this program to help understand how much of the time is spent on general overhead of reading the file and how much time is spent by Inventor or Apprentice actually doing the work they need to do.  As you can see, most of the time used by Apprentice or Inventor is system overhead of opening and reading the file.  Anytime you have to read or write data to a hard drive, performance will be slow.

1. VB.Net – 77.69 seconds

Summary
If you need to write a utility to manipulate iProperties, using Apprentice will allow you to create the fastest program.  However, if you just need to read iProperty data, opening documents invisibly in Inventor is almost as fast and a good alternative.  Remember that Apprentice cannot be used within an add-in.  If you need to do a lot of iProperty processing (writing and saving) through an add-in it might be worth creating a separate exe that uses apprentice that your add-in uses.  You need to be careful that those documents are not currently open in Inventor.

Gotcha
Here’s something to watch out for when doing any timing tests like those above.  The first time I ran a test it was slow and subsequent runs were significantly faster.  For example, when I first ran test 2 with Inventor it took 100 seconds and then running the same test a second time only took 4 seconds.  Even test 3, which doesn’t have anything to do with Inventor went from 77 seconds for the first run down to 0.338 seconds for subsequent runs.  What’s happening is that Windows is caching data in memory in case the data is used again.  This is great if you are reusing data but I think in most workflows where you’re batch reading and updating iProperties this won’t be the case.  To get the times reported above I rebooted between each test to clear memory and force the data to be read from disk.