Important info to help improve Revit's performance

[Wes Macaulay]

One of the things I've wondered as people start building larger projects in Revit is how to setup the project database so that you can draw as fast as possible... either with worksets, or some other feature of Revit.

Irwin Jungreis recently posted some very helpful information with regards to how Revit parses or interprets the RVT file into memory. The thread started with a discussion on Design Options:

Quote:
Originally Posted by andrewg
When I select the "Accept Primary" in design options, I'd like to be given a choice of what to do with the other options, i.e. write them out as groups or some other special design group, for possible later use.

I just hate to see all that work on the other options go up in virtual smoke.

Irwin Jungreis:
One possibility is to not Accept Primary -- leave the secondary options in the model. They take up some space on disk, but due to lazy parsing they will usually not slow down performance of most operations such as opening the file, saving, or displaying (since they are invisible). They will slow down save only when it is to a new file name. They can also slow down regeneration when you change something they depend on. For example, if you change a level height then any walls in secondary options that used that level will regenerate. However, most of the time, having the secondary options around won't slow things down.

In this case, "parsing" means converting the data from the form it takes on disk to the data structures used to represent it in memory. Most of the processing that takes place on opening the file is this conversion. Most of the memory used by the revit model in session is taken by these data structures.

"Lazy parsing" means that the data for each element isn't converted until it is actually needed. The main uses for the data in an element are to display that element or to regenerate it when there are changes to other elements it depends on.

What this means for performance of large files is that if you can keep large collections of elements from displaying, then usually they won't take time on file open and they won't take up memory. The exception is when there are changes to other elements they depend on, but in most revit sessions that won't happen for most of these elements.

Selective open of worksets is a good way to keep large collections of elements from displaying. Of course, that will also speed up display! If you have enough memory then the improvements to display performance are probably more important than the benefit of lazy parsing (there's no advantage to saving memory if you have more than enough).

Wes Macaulay
Here's another question then: if you're in a particular view, and the view range means that you're not seeing other objects in worksets that are turned on, will they get loaded into memory?

I guess the question is this: does selectively opening worksets make any difference if the objects that use them wouldn't be visible in the current open views anyway?

A theoretical application along the same lines: say I've got two connected buildings in a file, each in its own workset, and an enclosed walkway in a third workset connecting them. Then I've got plan views where I've cropped one of the buildings (and all objects on worksets used for the building) out of the view. Will there be any performance enhancements if I turn off the workset of the building that has been cropped out of the current views, even if I wouldn't be able to see those objects because of my crop regions?

Irwin Jungreis
In many cases, if an element will not be visible then the code can figure that out without parsing the element. In those cases, you won't get any performance benefit by turning off display of the workset. The best way to find out if that is happening in the cases you mentioned of clipping and view range is to try it out on your particular models.

The case to watch out for is hidden line removal. If an element would be visible were it not for the fact that there is something else in front of it, then the element must be parsed to figure that out. Those are the cases where selective open will give the biggest performance benefits. For example, suppose the view depth for level 2 is set to include things on level 1, but they are all hidden by the floor on level 2. Then putting all the furniture from level 1 on a workset and hiding that workset will not change the picture (since all of the furniture is hidden by the level 2 floor anyway) but it will draw faster and use less memory. In general, if when you change a view to Wireframe mode you see a lot of elements that you couldn't see in Hidden Line mode then there's room for improvement in that view. Try to find some other way to make those elements invisible so the software doesn't have to do hidden line removal to figure it out. For example, use workset visibility, category visibility, view range, or far clip plane.

[Wes Macaulay]

The upshot would seem to be... keep your view ranges minimised, and turn off worksets you can't see in a given view.

If there's any more to this that should be added Irwin, please do jump in. I also have more questions for you: on a non-workset enabled single-user file, is there some degree of demand loading that happens here? So if a view range is set only so wide, Revit only loads visible objects into memory?

I've worked on some substantial single-user files in 5 and 6 that would have blown up Revit 4.5 with worksets enabled, so part of my question is to compare the performance of:

• a worksets-enabled file where data is in a workset turned off
• a single-user Revit file where that same data would be outside the view range

In essence, besides the obvious fact that objects in worksets turned off are unlikely to be loaded into memory, how else do worksets improve Revit's performance?

[irwin]

I also have more questions for you: on a non-workset enabled single-user file, is there some degree of demand loading that happens here? So if a view range is set only so wide, Revit only loads visible objects into memory?

...compare the performance of:

• a worksets-enabled file where data is in a workset turned off
• a single-user Revit file where that same data would be outside the view range

In essence, besides the obvious fact that objects in worksets turned off are unlikely to be loaded into memory, how else do worksets improve Revit's performance?

Lazy parsing occurs for both worksets and non-worksets files. The only difference is that worksets can be used to make elements invisible. In a non-workset file if the same elements are made invisible by other means such as category visibility, view range, or design options, then you get the same benefits.

As to performance of workset and non-workset files, for most operations it makes no difference either way (unless you are using worksets to make lots of stuff invisible that would otherwise require hidden line removal). The only definite exception I can think of is that workset file backups are considerably more compact on disk -- the same number of backups takes a lot less space -- but you have to deal with the backup directory instead of individual backup files. There are some parts of saving a file that will be faster for workset files, but there is also additional work that must be done so overall it is unclear which will save faster -- it can depend on the particular file and what was changed.

[Wes Macaulay]

Thanks again, Irwin. I believe this is invaluable information for Revit users who either have pathetic hardware (like me) or who have monstrous files in which they are working.