ElementTransformUtils: Performance issue

[Revitalizer]

Hi Autodesk,

I have a bunch of FamilyInstances that must be

1. created
2. parameterized
3. moved and rotated

I mentioned a significant performance decrease when doing the third point, there is a factor of 50.

Creating and setting parameters works like a charm, the operation is finished within the blink of an eye.

But when I move or rotate elements afterwards, this will slow down the operation.

• My family is neither element hosted nor face hosted.
• My TransactionMode is "manual".
• During the process, there is no document regeneration invoked.

Seems that just moving elements triggers some internal checks.

So, here is my question:

Is there a way to disable Revit's consistency checks, temporarily ?

Something like the "virtualmode" when filling a DataGridView control...

If not, please put it on the wish list for the next Revit version.

Revitalizer

[jeremytammik]

Dear Revitalizer,

Thank you very much for reporting this.

Please submit a minimal reproducible case for me to pass on to the development team, both to prove the problem exists and to prove that it is resolved, if possible:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

Mille grazie!

Cheers,

Jeremy

[arnostlobel]

In fact, I have already started a discussion about the case here (the Revit R&D). Since the transform utils are largely based on internal copy & paste code it is very likely there are some intermediate regenerations going on when even translating elements. However, we do not think regeneration alone ought to be dramatically slow unless something else si causing the slowdown. Revitalizer mentioned that his instances are non-hosted, but without actually having those instance on hand we cannot pin-point the problem.

To be accurate and honest, we too agree that there should be no regeneration involved in the individual transform. Alas, there are now, and it'll take a while before we'll be able to refactor the code. It is on our list, though, and we are aware of the problem.(Again, in most cases, the intermediate regeneration ought not to be a source of dramatic slowness, at least in the cases as discussed here.)

[jeremytammik]

Dear Rudi,

Thank you for your sample material communicated by private email.

I attached them to your ADN case 11025652 [ElementTransformUtils: Performance issue] and logged the issue REVIT-74269 [ElementTransformUtils performance] with our development team for it on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

I hope this helps.

Cheers,

Jeremy

[mahmouds12]

any news about this?

[mahmouds12]

Dear Jeremy,

Any news about this issue

[jeremytammik · Accepted solution]

Dear Mahmouds12,

Nothing new beyond what I communicated above to Rudi:

The development team analysed the issue REVIT-74269 [ElementTransformUtils performance] that I submitted on your behalf.

We have concluded that the element transform utility functions should be rewritten without relying on the copy-paste framework. That is a major project from the "maybe someday" category, so I will close this with "Code fix needed."

The new case number now is REVIT-74636 [ElementTransformUtils performance].

Furthermore, the development team upgraded its importance to 'Major'.

However, there is no saying how long this will take.

I am still waiting for Rudi's reproducible case...

Best regards,

Jeremy

[mahmouds12]

Thanks Jeremy...

Until this issue is fixed, is there any workaround that can be done to rotate Revit elements without relying on ElementTransformUtils?

Best Regards,

Mahmoud S. Habib,

Handaz LLC

[Revitalizer]

Hi Jeremy,

I'm confused:

"Thank you for your sample material communicated by private email."

"I am still waiting for Rudi's reproducible case..."

I don't remember the content of my email, but "sample material" sounds like "reproducible case".

😉

Rudi

[Revitalizer]

Hi,

if your Element's Location is a LocationPoint, it has a Rotate(line, angle) method.

If it has a LocationCurve Location, its Curve property may be set by a transformed/rotated curve.

Revitalizer

[jeremytammik · Accepted solution]

Dear Rudi,

On my prompting, the development team revisited the issue REVIT-74636 [[API] ElementTransformUtils performance] and say:

1. We don't have a fix planned for this yet. And the work required would be significant.

2. I agree. This issue hasn't been prioritised by our team. From reading the comments and the forum, it sounds like there is no quick fix for this issue and that the utility needs to be rewritten to not use copy-paste framework. We are currently prioritising other initiatives. Please reach out and provide a business case if you want to escalate this further. Sorry about that.

Also, I would suggest submitting an API wish to the Revit Idea Station for this and collect many votes for it to underline its importance to the add-in developer community.

Thank you!

For the moment, as a workaround, I would suggest using other means to apply a transform to a large number of elements, enabling you to control the transaction handling explicitly yourself.

I hope this helps.

Cheers,

Jeremy

[alexpaduroiu]

Well I hope is not too late, but I found a solution using ElementTransformUtils.MoveElements instead of Moving each an every element from an iteration. 

So basically I have created a Dictionary with XYZ keys and List of Elements values:

Dictionary<XYZ, List<ElementId>> elementsToMoveDictionary = new Dictionary<XYZ, List<ElementId>>(new XYZEqualityComparer());

Of course for this dictionary to work I had to make a equality comparer...

class XYZEqualityComparer : IEqualityComparer<XYZ>
    {
        public bool Equals(XYZ a, XYZ b)
        {
            return a.X == b.X && a.Y == b.Y && a.Z == b.Z;
        }

        public int GetHashCode(XYZ x)
        {
         //GetHash
        }
    }

After the iteration of elements is done I'll just move a Lists of elements:

foreach(XYZ translation in elementsToMoveDictionary.Keys)
{
ElementTransformUtils.MoveElements(doc, elementsToMoveDictionary[translation], translation);
}

This will not help if you have lots of different translations, but for my problems worked like a charm because I had a lot of Elements that I had to move with same translation.

[fwang52MYR]

Troubleshooting my plug-in for performance issue led me here.... 

Method in question for me is ElementTransformUtils.RotateElement() in RevitAPI 2022

I have a bunch of instances (up to about 150), each have a different axis and angle for rotation. I notice that under certain condition, it slows the process significantly. 

Is it fixed in 2024? Or are there workarounds for this? 

Thanks

[jeremy_tammik]

Rotating 150 instances ought to be very quick. What conditions are slowing it down for you?

[fwang52MYR]

I don't fully understand the conditions but roughly:

When the elements being rotated is in contact with a link architectural model, or even just generally within that architecture model (e.g. inside a room, midair), this method slows the program down considerably in comparison of doing the same away from the link model. 

Another thing that I've noticed is that the document is being regenerated many many times in some cases where it is slowed.

I'm not sure if it is this particular model's problem, but it happens. So far, I've only noticed this one case. Runs nicely otherwise.

I'm using RevitAPI 2022 in Revit 2024.