Size and Performance "Bang for the Buck"

[phyllisr]

One firm's experience...

We have been monitoring model size and performance as our projects get larger and larger in an effort to provide some internal best practice recommendations. We have discovered a few things on an anecdotal level. Since we get asked this question internally, I thought I would share the results of our totally informal, unscientific test on a smaller model. This affects how we create families and when we do or do not provide Type Catalogs. And how much stuff we would prefer came OOTB with Type Catalogs.

Compacting regularly is important but this only gets a 5% size benefit (more with multiple staff/teams in the same project). The 20% benefit comes from eliminating unused content and then compacting the file.

Size When Opening: 35 MB
Size after Compact: 33 MB
Size after Audit and Compact Again: 33 MB
Size after Purge Unused and Compact Again: 28 MB
Size after Audit and Compact One More Time: 28 MB

As I said, this is informal and not statistical gospel. However, these percentage results seem to hold true even in the larger projects with over a million SF and multiple floors approaching 100 MB to 200 MB.

[jeff.95551]

We've got a guy here who's spent quite a bit of time playing with this -
Assuming you're using worksets, file size isn't really a factor, except when you open the file the first time. A compacted file is faster - big files we try to compact at the end of the day. We tried a purge all unused, and lost all kinds of things we wanted in the file. Whatever performance gains might have happened, they were more than killed by having to load a bunch of stuff back into the project. And if you use templates, you should never use the purge all unsed tool.

I try to remind people that even slow performance in Revit is about 8 times faster than lightning performance in Autocad...

[Wes Macaulay]

The killers of Revit: number of objects and numbers of relationships. Keep both minimised.

File size hasn't directly translated into death of performance. For instance, make some objects with spline profiles and spline paths. You'll get file size fast, with little loss of performance.

But take a large floor, and join geometry after completing the sketch with a few score walls, and watch performance degrade mightily as a result.

We've watched performance improve after conglomerating a whole kitchen into one überfamily that has all millwork, stove, etc. in it, and adding that across 120 unit groups. Thanks to Zed for that tip.

[ron.sanpedro]

[b]
We've watched performance improve after conglomerating a whole kitchen into one überfamily that has all millwork, stove, etc. in it, and adding that across 120 unit groups. Thanks to Zed for that tip.

So was the performance increase due to making the thing an uber-family, or because the family was used in groups, or both? I know I had hoped that using groups for Unit Plans would improve file size, but it does not. My next test is to compare linked files with Worksets for a huge project. I am hoping good use of Worksets will allow us to not break up big tower projects into multiple files, but we shall see.

Best,
Gordon

[Dimitri Harvalias]

So was the performance increase due to making the thing an uber-family, or because the family was used in groups, or both? I think what Wes is getting at, and from my own experience, if you have a single family that contains ten objects then Revit only has to keep track of one element (the family) and its relationships with other Revit objects, instead of having to consider all the individual objects. This is where the performance gains occur. I don't think groups are quite as effective, but they will help.

It's not all about file size. That might impact in ital load times but during working times it's the number of objects and their relationships that Revit needs to keep track off.

[phyllisr]

It's not all about file size... it's the number of objects and their relationships that Revit needs to keep track off.
Actually, it is both. We have two offices and work through a WAN. We also allow staff to work at home through a VPN connection. Network space is not free no matter what the file extension. Though our overall project folder sizes are beginning to decrease (a Revit model is significantly smaller than the total of all .dwg files it takes to issue the same set of documents), our projects are getting larger and more complex. File size is not the only thing but it is certainly an important factor.

I do agree about the performance issue. That is another reason we purge unused content (with caution for obvious reasons). Residual decals, raster images, complex families, old in-place families, masses no longer needed and more are significant culprits in performance problems.

We have also seen that purging unused saves raw productivity time and limits frustration. It results in less time wading through long lists in the Type Selector of junk some other team member did not bother to remove. Or name in any intuitive way...

[phyllisr]

We tried a purge all unused, and lost all kinds of things we wanted in the file. And if you use templates, you should never use the purge all unsed tool...
Never seems a strong word. Proceeding with caution is my preference. It helps to provide Best Practice tips to your staff. Remind them to Check None and selectively purge content. We have a document posted to our intranet explaining how to do this without losing content we know will be needed eventually. And how to do this without losing system content that is difficult to add back to the project.

[dbaldacchino]

Use of Purge Unused should be accompanied by a careful review of all the checked boxes, and not just blanket-accept everything that Revit checks.

One thing I noted about file performance (local files) is that people tend to work and save and save and save....and never compact their locals. So a file that should be 88MB ends up being 118MB and it does react slower. Compacting the local really helps (yes I know, some create locals every morning....at this time we don't). Now how about also giving us options to compact both the local and central file in the STC dialog?

[Wes Macaulay]

I do agree about the performance issue. That is another reason we purge unused content (with caution for obvious reasons). Residual decals, raster images, complex families, old in-place families, masses no longer needed and more are significant culprits in performance problems.

We have also seen that purging unused saves raw productivity time and limits frustration. It results in less time wading through long lists in the Type Selector of junk some other team member did not bother to remove. Or name in any intuitive way...I can confirm this too -- very good points, Phyllis!

[Elmo]

We have noticed that Autocad files are a big no no. If you can get rid of them when your done with them. Don't just delete and think it's all gone though. Make sure you have removed all the layers that were brought in by going Settings>Object Styles>Imported Objects.

Another issue we have come across is that if you create a lot of in place families it makes the project real heavy.Another little trick we have come across is that if you go File>Save As and rename your project it also makes the file size smaller.

[jeff.95551]

Never Proceeding with caution is my preference. It helps to provide Best Practice tips to your staff.

Good Point - I know it isn't as quick, but our best practice is to expand all of the families and groups in the browser, and go through them one by one. If you delete a family or group there that is used, it tells you. Probably not as complete, but also not as dangerous, and it forces the user to be thoughtful about what is getting removed.

[phyllisr]

Another little trick we have come across is that if you go File>Save As and rename your project it also makes the file size smaller.
This does work but I would suggest your staff exercise considerable caution. We enable worksets in every project from the earliest phase. One of our huge challenges is changing the .dwg mindset wherein SaveAs means a whole new file. This is not the case when worksets are enabled. I could take a vacation to Tahiti on the billable time we wasted in the early days of migration "fixing" problems where SaveAs was misunderstood.