How big is your file?

[Archman]

Quick Poll:

How big is the largest central file you have worked on?

Ours is currently 85 Mb and getting pretty sluggish. Started getting sluggish around 60MB.

P.S. Moderators, you can move this post if it's not in the appropriate forum.

[gregcashen]

I would suggest that it's time to do a saveas of your central file. This can halve the size of your files. It must be a saveas, though, not a simple save. Also, try purging any unused families, types, etc. If you have renderings in the project, I would export them out and not link/import them in until CD phase.

[Wes Macaulay]

File size doesn't mean you're life is going to be slower... it's the number of relationships between objects. I've got 10Mb files that run slow and 50Mb files that zip along! Greg's got the CW on this one tho -- you do need to do a save-as now and then if your files are bloating.

[beegee]

Scott Brown had some interesting observations on things that affect performance in Revit files :-


1. number of constraints
2. number of 3d objects, ie more wall pieces/3d toilets, etc.
3. NOT SQUARE FOOTAGE, I've had 10,000 sf office buildings that are barely useable(5.1) and 100,000 sf offices(recently a test 400,000sf hotel) that move quickly. Its all in the constraints and 3d geometry that has to be regenerated and recalc.

4. Compound walls and hosted sweeps, these effect performance.
5. Almost all of this can be helped with proper management of these objects with visibility and worksets.

[gregcashen]

Wall sweeps and vertically compund walls have taken a completely workable Revit file and slowed it down to a crawl. I stay away from this stuff until the end of modelling.

[sbrown]

On a large file it is critical you utilize worksets properly. Use selective open when opening your local file so you don't load the whole model into your memory, this also reduces save time because you only are saving your portion. Note it will be quick to save to central if the team saves to central more frequently. I recommend every 30min-1hour. Revit typically recommends at lunch and end of day, but I disagree completely due to errors I've had saving to central. I save to central after any chunk of work I do that I don't want to have to redo if there is ever a problem saving to central. File size as others have mentioned has nothing to do with performance(maybe a little). Make sure your local file is on your local machine that will improve the local saves(which are much longer than central unless central saves have to reload a lot of worksets that other users have edited.

Using selective open is key on large projects.

[Archman]

I would suggest that it's time to do a saveas of your central file. This can halve the size of your files. It must be a saveas, though, not a simple save. Also, try purging any unused families, types, etc. If you have renderings in the project, I would export them out and not link/import them in until CD phase.

We do a saveas quite often, once a week or so. We only have one rendering in the project which is on the cover sheet. We are about to issue 100% CD's on this 190,000 SF arena. It has very conplicated geometries and structure and lots of in-place families (possibly one of the cuplrits for the file slowing?)


Compound walls and hosted sweeps, these effect performance.

How do you show reveals in walls then? Do you just draw drafing lines on the elevations? If so, it seems to go against the whole premise of BIM.


On a large file it is critical you utilize worksets properly. Use selective open when opening your local file so you don't load the whole model into your memory, this also reduces save time because you only are saving your portion. Note it will be quick to save to central if the team saves to central more frequently. I recommend every 30min-1hour. Revit typically recommends at lunch and end of day, but I disagree completely due to errors I've had saving to central. I save to central after any chunk of work I do that I don't want to have to redo if there is ever a problem saving to central. File size as others have mentioned has nothing to do with performance(maybe a little). Make sure your local file is on your local machine that will improve the local saves(which are much longer than central unless central saves have to reload a lot of worksets that other users have edited.

I agree with you completely. Selectively opening and frequent saves are something we haven't been very disciplined about. :oops:




I have also noticed that saving to central takes a lot longer if someone on the team is trying to make a workset editable while the save to central is being performed. We have begun adopting an unwritten rule that if you get the message that someone else is accessing the central file, to cancel and try again after that person has finished saving to central.

Belive it or not, this scenario happens quite often (We have four users actively woking on the project at one time.)

I have to believe that the constraints are the culprit for sluggish response. I think it is related somewhat to file size though, because as the file grows, the more "automatic" contraints Revit is creating. That's my theory any way. I have no proof to back it up.

Edit: I just reread this post, and parts seemed like I was flaming. Sorry, I'm having one of those days. I love this forum and the help it has provided. I don't know what I would do if I couldn't use this forum as a resourse. So I''m raising my glass and saying a big thanks to ZOOG!

[gregcashen]

We do a saveas quite often, once a week or so. We only have one rendering in the project which is on the cover sheet. We are about to issue 100% CD's on this 190,000 SF arena. It has very conplicated geometries and structure and lots of in-place families (possibly one of the cuplrits for the file slowing?)

My biggest Revit project is 5000sf, so I am speaking from my experience which is of limited help to you. I think for a project that size and complexity, you are going to experience slowdowns of some sort. I would say, based on this, you should probably go Scott's route, and use worksets heavily to reduce the amount of open geometry.

The thing about the wall sweeps is that if you do a VCW, then make a copy of the wall without the sweeps in it but the same geometry otherwise. Then, get the sweeps right and swap out the wall. Don;t swap it back until later. Or use visibilty to turn wall sweeps off in your views if you don't need them visible. They really slow my files down alot.

No worries about the flames...I'll get ya back ;)

[sbrown]

Reveals is a tough issue. I like to model them but I hate that on my elevations you may see 4 lines (because on a precast wall reveal you would really see 4 lines projected) this is way to heavy for an elevation where you may just want to see a single line that represents the reveal.

I like Gregs suggestion about building a compound wall with the reveals in it and swap it out for rendering when needed and then use model lines with their own linestyle for the reveals so they can be turned on and off.

I'd love some way to have a course and fine view of a reveal.

[gregcashen]

I'd love some way to have a course and fine view of a reveal.

Me too. Or visibility settings like elements in families.

[Kroke]

22 mb is how big my current one is. No renderings.

[Wes Macaulay]

Scott Brown had some interesting observations on things that affect performance in Revit files :-

Oh man -- this is right on the money. I tell people to not use vertically compound walls when we teach Revit (sorry Revit development team :( )... they just cause more problems than they solve.

Constraints really can be a problem... funny, but true.

Phil Read's notions about making the Revit model more inert, more static, really stand out. It's not the complexity of geometry as the complexity of the relationships between them.

[JamesVan]

Constraints really can be a problem... funny, but true.

Phil Read's notions about making the Revit model more inert, more static, really stand out. It's not the complexity of geometry as the complexity of the relationships between them.

I don't see constraints as a "problem," as much as a "power." If one possesses too much "power" they run the risk of corruption and abuse. Our #1 rule is don't over-constrain the model or the family. Recognize where constraints are most applicable and where they are not.

Also, be careful with modeling certain components that can be handled with a 2D version like toilets or sinks. If you don't need bathroom renderings or elevations, use 2D families instead.

[Wes Macaulay]

Absolute power corrupts absolutely, eh? Ha... constraints are a two-edged sword!