element.document performance with A360

[MattKincaid]

We've written an addin that calls the element.document property many times (see code snipet for an example).  I've found that when the user is using A360, the calls to element.document are rather slow (each call takes about 2 seconds).  With files that don't use A360, the calls to element.document are much faster.  Has anyone every delt with this problem or found a solution besides just minimizing calls to element.document?  Thanks.

Snippet

Friend Function GetElementDocument(e As Element) As Document
 
    'The following line of code takes about 2 seconds to execute when using A360.
    Return e.Document
 
End Function

[jeremytammik]

Interesting... checking with the development team for you...

[Anonymous]

cheers for speaking up about this, I use Element.Document rarely because my framework automatically caches the document at the beginning of each External Command and Updater call, but I have a few general purpose methods that are decoupled from the framework that use this property. I might go hunt them down and change them to see what speed advantages I can get. I've found that when the document is located on our (very slow) network server my add-ins really slow down. I think it could be Revit accessing the file on disk (or cloud in your case) for larger queries using slow element filters. My users are always complaining about response times. You'd think they'd be happy to wait a few minutes looking at a progress bar (or grabbing a coffee) while my add-in saves them several hours work... 

[jeremytammik]

Dear Matt,

The development team respond:

We are not aware of any reason whatsoever why the Element > Document lookup would be especially slow.

We need some more details to explore and understand the issue.

• Is the document loaded into Revit from an A360 path?
• Is Collaboration for Revit also involved?
• Is it just as slow to get the document from UIApplication.ActiveUIDocument.Document?

A reproducible case would help:

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

Thank you!

Cheers,

Jeremy

[MattKincaid]

Thanks for investigating this Jeremy. I will be traveling all next week and will have to wait until I return to investigate the answers to your questions and mock up a test case.  But I will update you with what I learn.

Out of curiousity, do you know if the developers actually tried to call element.document in an A360 enviornment?  Or are they just hypothesizing that it shouldn't be slow?  If they have tried to reproduce the problem and can't easily do so, that would be an interesting piece of information to learn.  I've noticed this problem on every A360 file I've tried. But perhaps there is some file specific problem or A360 configuration problem that is at play.

Thanks for the help.

[jeremytammik]

Thank you for the update.

And thanks to Scott for the caching recommendation. Very simple and sensible. KISS!

I expect they did not test. They are very busy indeed. Hence the need for a reproducible case to communicate clearly and unequivocally.

Safe travels!

Cheers,

Jeremy

[MattKincaid]

Ok, I'm back in the office and am in a state where I can begin investigating this further.  Before I do, I wanted to ask what you think the probability is that the development team will take this seriously, if I am able to mock up a simple test case.  The caching the document approach would be pretty easy to implement.  So if this kind of stuff is a low priority for Autodesk, I can just take that approach and save us all some time.  But if you guys are interested in working on it, I would be more than happy to provide my assistance.  Just let me know.  Thanks!

[MattKincaid]

Hi Jeremy,

I've learned a few more things regarding this issue and thought I would upate the post with my findings.

1.  I made an error in my original post.  You guys were correct that there are no problems whatsoever with the element.document property.  The problem actually lies with the Document.PathName property.   I appoligize for the diversion.  I would be happy to start a new post, if that is better.

2. The problem with Document.PathName occurs when the user is working in an A360 enviornment and the document is a linked document.  Those seem to be the 2 critical factors.

As far as mocking up a test addin to reproduce the problem.  I haven't found the time to do so.  We are currently in the process of modifying our code architecture to just work around this problem.  So we don't really need a response/resolution at this point.  I just wanted to update the forum post with what I have learend.