General workflow for keeping track of elements

[cwaluga]

Hi, I am not sure what is the best way to accomplish what I indend to do. My scenario is that I am working completely integrated in Revit, so no import/export/worksharing issues for the moment. However, I have to keep track of the elements (some types only, not every single element of every single type).

Now if I understand correctly, it is discouraged to rely on Element IDs, since those may not be unique in linked scenarios and may even change within a document. Instead it is recommended to use Unique IDs for this, but the API makes working with these not easy. Moreover, if I want to obtain an Element from an ID, I have to know the document as well. I could now always check all documents if they contain an element or always store a reference to the document alongside with the ID. I could however also work directly with the elements. They know which document they belong to and in case I need something from the element, I do not have to create one from the ID first. However, if I recall correctly, I read some time ago that this may be inefficient. Is that so?

TLDR: To put it in one short question: Is it alright to excessively keep references of elements around? If not: why? And is there a better way?

[jeremytammik]

Dear Cwaluga,

I would simply keep an eye on the trends set by the Revit API implementation itself.

It is consistently moving away from passing elements as aruments, and using element ids instead.

Therefore, I would agree that what you are doing is best:

• When storing stuff for a duration exceeding the length of one single Revit transaction, use unique ids.
• When storing element information just for passing around within one transaction, use element ids.
• Only access the element itself when you need to.

I hope this helps.

I also hope Arnošt will correct me if he disagrees in any way or has anything more to add.

Thank you!

Cheers,

Jeremy

[cwaluga]

Thanks so much for your suggestions, Jeremy. I'll try to avoid keeping the elements alive more than necessary. But there are some points revolving around this, which are not obvious from the documentation.

If I may add two short follow-up questions:

1) Is there any way to obtain a UniqueId from an ElementId without instantiating the element first?

2) How expensive is the element instantiation really? Would a good rule of thumb be that unless you are in a part of your code which needs frequent element access, you are better off with using doc.GetElement whenever needed?

[arnostlobel · Accepted solution]

(I am sorry for the delay – have been busy lately).

I'd say it's fairly all right to store and work with Elements directly, in the public managed API anyway. We've made quite an effort to make element objects stable no matter how (and if) the model from which the elements are changes. The same does not apply internally in Revit native code where we need to be more cautious of memory re-allocation, which is why, internally, we generally prefer working with Ids. That general approach mirrors in the public API, for our goal is to have a public API that is as close to our internal API as possible.

So, my general recommendation would be:

1. If there is work-sharing involved, stick with unique Ids;
2. If work-sharing is not involved (and if you can somehow guarantee that), you can work with either elements directly or with Element Ids (or Unique Id, naturally), whichever way you prefer and are more comfortable with.

There is one point of caution: I've stated that we had made elements quite stable. That is certainly true for most kinds of element, but not for all, unfortunately. There are (I believe) still a few older kinds of elements that do not yet have an “ironclad” wrapper around them. Basically, if an element class does not have the IsValidObject method in their class, those elements would not be safe to hold on to, because in case the actual elements are deleted (or undone, or redone, of if their document got closed), the managed object would not know about it and any operation performed on it would lead to a crash. So, if you store elements make sure it's the kind which has the IsValidObject method, and grow the habit of always testing that method before every use of the element.

As for performance impact, there are, again, a few points I'd like to make:

1. There is practically no performance degradation from fetching an element by its Id.
2. Naturally, element Ids are smaller to store – they hold only an integer, while most Elements (the managed objects) contain at least two pointers and some flags also.
3. Once you have an element (in the API), there will be no slowdown or memory impact. It is because once an element is read and brought in to memory, it stays there until its document is closed or the element is deleted in some work-shared action. However, there are plenty of methods that give you element Ids of elements that have not been completely read from the memory yet. Revit is pretty savvy (some may say lazy) about what part of an element is needed and which can be deferred until later. So, if an API application is given a list of elements and immediately fetches the corresponding elements so it could store them, that application may in fact have negative impact on Revit performance, because Revit would have to completely read those elements and have them in memory.

Oh, and to answer some of the question cwaluqa asked:

1. No, it is not possible to obtain Unique Ids from a given Element Id.
2. Element instantiation (the API managed object) is not so expensive. However, as I pointed above, it would be expensive if the elements has not been completely read and brought to memory yet. We might have its Id already, but if the element is not completely available yet, we'd need to read it from the file, allocate native memory for it (which may be significant), and then allocate the public API object for it.

[cwaluga]

Brilliant answer Arnošt! I think I'll have to read this a couple of times to digest what you wrote there. Thanks for this insightful piece of information.

[jeremytammik]

Thank you, Cwaluga, for raising the issue, and Arnošt for the extensive answer.

I edited and published the discussion for posterity:

http://thebuildingcoder.typepad.com/blog/2015/09/family-category-element-ids-transaction-undo-and-up...

Cheers,

Jeremy