EA Enumerator Slow

[typeme2]

I'm making an addin to EA using Interop.EA.dll. The addin loops through all of the elements, attributes, and packages in a repository, and does some work on those objects.

The problem is that this process is very slow. A profiling session shows that the bottleneck is the EnumeratorViewOfEnumVariant.MoveNext() call. This call is taking up about 85% of my runtime. I invoke this call whenever I make a for loop to loop through one of the EA collections. For example,
foreach (EA.Element element in package.Elements){}

Why does this call take this much time? Is there a more efficient way to access the repository?

Thanks.

[«Midnight»]

Perhaps it is just the overhead of casting from a COM object of unspecified type. I doubt it though, since you'd have to do the cast anyway.

If it is an overhead related to the foreach construct (or its underlying enumerator setup) you might try traversing the collection by element index. You would have to declare an index and use the collection.getat() method, and still cast the result (I think).

Remember that the index should be a 16 bit integer; this is not always important, but I've seen some side effects from using 32 bits.

David

[typeme2]

I did try using the GetAt() method instead of the Enumerator MoveNext(), but that just shifted the bottleneck to the GetAt() method and did not reduce the run time.

[«Midnight»]

As a long shot, I wonder if EA is being chatty with the database - it has a habit of doing so.

Perhaps there is a way to get around the problem. Using the Project interface get the list of 'things' you need. Use one of the enumeration functions that returns an XML stream. Note that there are several such lists available, but not all collections can be enumerated. Now parse the XML - using something like XMLDocument or XElement (the latter should be much better, but you'll a recent version of .Net). For each of the 'things' you need, call the Get<thing>ByGuid method of the repository. This will return the 'thing' in question, without accessing the collection at all. As a benefit you will not have to cast the result.

Does this get around the bottleneck?

David

[typeme2]

Thanks for the feedback David. I tried your suggestion. The code to generate and parse through the XML was fast, but the Repository.GetXXByGuid() pretty much killed any hopes of a performance gain. Is there some function that I use to limit the scope of a search, something like Element.GetXXByGuid()?

[«Midnight»]

No. I'm afraid you're stuck. Remember that whatever you do, a call to EA is a call to a COM application. This is an expensive data transfer, all the more so when you are working with managed code (as in C#). It simply will not get too much faster.

You could do some manipulation by tweaking the underlying database, if you need to write back to EA. If you don't need to do so then you could grab several XML extracts, or export a package to XMI, and do all your work there. Note that if you use the XMI route you'll have to drop a file onto storage and then read it back; sloppy, but that's all we can do. You could even manipulate the XMI and import it back into the package - which you can do from a string variable (for some reason) - to update your project.

Depending on any concurrency issues you might have the XMI option might be your best bet. There's some work involved - but you have to invent something anyway - but the techniques can be reused in other EA projects. The payoff in time saved has been handsome when I've gone this way.

David

[Eve]

There is a cache mechanism you can enable on a repository that will give a small improvement in speed.  Other than that, I know one user who is no longer on this forum implemented a local cache and found that it helped.