Garbage Collection Revit Documents

Garbage Collection Revit Documents

Anonymous
Not applicable
1,222 Views
3 Replies
Message 1 of 4

Garbage Collection Revit Documents

Anonymous
Not applicable

Hi everyone,

 

I am currently writing a C# add-in that goes through a collection of Revit Projects and runs some file tests against them. My add-in runs reasonably fast and well, and I am able to properly get the data that I want out of the Revit Projects.

 

My problem lies in the way I am suspecting how Garbage Collection works using the Revit API. I have personally never done any memory management in programming other projects separate from Revit, so I may be speaking out of ignorance. The way my add-in works is that it opens the Revit project in the background (detaching it if its a central copy), runs the tests against it, then closes the project without saving by using the Document.Close(false) method (false meaning do not save the document). After my Revit add-in has run through all of the files, I find that Revit's memory usage has ballooned up by quite a bit (For example, before running the add-in Revit was only using ~600MB of memory, but after the Add-In has run, Revit reports that it is using ~2.5GB to sometimes over 5GB, but this is dependant on the number of projects I am running the tests against.)

 

What I have tried so far:

  • Using the Document.Dispose() method after closing the file, but this doesn't seem to help too much.
  • Explicitly calling GC.Collect(), but this doesn't free up memory either and just increases computation times instead.

I have read online that the inherent Garbage Collector in .NET only takes care of native library objects, but does not know what to do with un-managed resources created by third-party libraries such as Revit API objects. Would this mean that I would have to implement my own IDisposable class and methods? Would there be some sort of external library that could be used to manage memory better?

 

Thanks for any advice or recommendations.

0 Likes
1,223 Views
3 Replies
Replies (3)
Message 2 of 4

jeremytammik
Autodesk
Autodesk

Dear Mohsen,

 

Thank you for your query.

 

I do not think there is much you can do to fix this using garbage collection, I fear.

 

Keep in mind that Revit is not created for batch processing.

 

The Forge Design Automation API for Revit enables batch processing in the cloud:

 

https://thebuildingcoder.typepad.com/blog/about-the-author.html#5.55

 

Here are some hints and workarounds for batch processing with Revit on the desktop:

 

https://thebuildingcoder.typepad.com/blog/2015/08/batch-processing-dwfx-links-and-future-proofing.ht...

https://thebuildingcoder.typepad.com/blog/2019/04/batch-processing-and-aspects-of-asstringvalue.html...

 

Reading your description above, it would seem to me that an easy solution for this would be to simply shut down and restart Revit for each new document that you process.

 

After all, the time taken by Revit to just open the document is probably longer than the time to restart, so the performance hint might be quite negligible.

 

I hope this helps.

 

Best regards,

 

Jeremy

 



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

0 Likes
Message 3 of 4

FAIR59
Advisor
Advisor
0 Likes
Message 4 of 4

Anonymous
Not applicable

Thank you both for providing some solutions. In the end its seems to have not been too much of a problem for our PC's, as using the add-in to run on approximately 30 projects ranging from sizes of about 100MB to 300MB, memory usage did not seem to go over 5-6 GB during the duration of running the Add-in I developed. I expected it to be much worse than this, but it seems that everything is fine with its current functionality.

0 Likes