Memory Consumption Issue

[darren.braynard2]

We are running an automated Revit instance against a model where many views are opened one after another and each time we perform read-only processing of the elements in each view. The problem is that memory continues to grow throughout the processing. Attached is an image of memory/cpu usage for a job that processed 61 views. We have added a call to Application.PurgeReleasedAPIObjects between processing each view, and made a call to View.Dispose() as well. However, memory continues to climb. What other steps can we take to prevent memory growth during processing?

The test was with Revit 2015. The plot in the attached image includes 2nd y axis that shows the CPU usage. Memory series are using the 1st y axis.

[jeremytammik]

Yes, well, Revit was designed to be used and driven by a human being through the end user interface. When you drive it programmatically like that, you must expect to hit a limit sometime.

Check out these suggestions:

• http://thebuildingcoder.typepad.com/blog/2014/12/au-ends-and-batch-rendering-across-several-projects...
• http://thebuildingcoder.typepad.com/blog/2015/08/batch-processing-dwfx-links-and-future-proofing.htm...

Good luck and have fun!

Cheers,

Jeremy

[darren.braynard2]

I appreciate the response. These are great resources. Though, we are hoping for a technique within the Revit API, since we are not in direct control of the Revit.exe process itself. If we could break up our job into smaller jobs, we could avoid the problem, but it would not be ideal.

Thanks,

Darren

[jeremytammik]

I cannot think of any other feasible approach. Sorry!

[FAIR59]

I'm wondering, do you need to open the view to do read-only processing??

[darren.braynard2]

I believe so, the elements are processed according to which view(s) have them visible.

[jeremytammik]

Very good question! You could try NOT to open any views at all... what do you need views for?

[darren.braynard2]

We are using each View object in a call to FilteredElementCollector in order to obtain its visible elements. We are not really "opening" the GUI view.

[jeremytammik]

Good. Then I am afraid there is little else one can suggest...

[FAIR59]

One final suggestion: where do you store the results of the read-only proces??

[darren.braynard2]

We send them out to an external database.

[FAIR59]

I see no pure API method to release memory. But by tapping into the UI, there is a possibility .

As an user I can release memory by opening the workset-dialog in a workshared project. This command has a CommandId and hence you can use PostCommand to show the dialog.

Using the dialogshowing event, you can then close the dialog and raise an external event to get control back.

This method isn't "pretty"( the dialog is visible for a split second ), but should work.

revit.Application.DialogBoxShowing += Application_DialogBoxShowing;
revit.Application.PostCommand("ID_SETTINGS_PARTITIONS");



void Application_DialogBoxShowing(object sender, Autodesk.Revit.UI.Events.DialogBoxShowingEventArgs e)
        {
            if (!e.DialogId.Equals("Dialog_Revit_Partitions")) return;
            UIApplication uiapp = sender as UIApplication;
            uiapp.DialogBoxShowing -= Application_DialogBoxShowing;
            // raise external event here to get control back
            e.OverrideResult(
               (int)TaskDialogResult.Close);
        }

[darren.braynard2]

Thanks @FAIR59. This sounds interesting. I will give it a try and report back my findings.