Revit's platform team has compiled a document called:
"revit_platform_2009_model_perfomance_technical_note"
It is available, at least, via the Subscription Center. You'll have to log in to gain access to it there.
I'll mention one specific item in this post for now:
Attempt to keep project team workstation specifications equivalent. A dramatically weaker machine specification used by a single team member can reduce overall project performance.
Moral of the story, don't let support staff access the model with their mid 90's era pc's (exaggeration perhaps) to enter data into schedule for example.
This isn't in the document, I'll add it here, the above reminded me of it:
When Saving to Central (STC) stay until it finishes succesfully. If it fails, any error message that might occur will need to be resolved. If you have wandered away or are in a meeting this error message will very likely prevent others from using STC successfully.
I've posted a copy of the document HERE assuming that Autodesk wouldn't object to any Revit user having it regardless of subscription status. It is possible that they might ask me to remove it however. If so it will be removed.
2 comments:
I went through this document. My firm has tried all of the above, and done much more with regard to the hardware. And I always try to make sure we economize on file sizes by not modeling unnecessary geometry.
What I have come to realize is that Revit is just not cut out for large projects. The blame lies totally with the Revit development team at Autodesk. Why cant they write code so that these files don't get bloated or at least their platform uses all the memory and processing power the hardware has to offer. The program does not support multi threading, nor is it 64 bit compaitble. They talk a lot about breaking down the model into smaller files and linking them. But do they support tagging elements in linked files? No! Also they say you can schedule objects from linked files. True you can but not as simple as they tell you it is and like always you have to find your own way around their quirks.
Autodesk must label this product as "Warning: For Small Project Only. Using on large projects can cause severe headaches and may even result in nervous breakdown".
Recently I took one of our revit model files (which I am having a hard time with) into Navisworks. I must say it worked like a charm, it was more like a video game not a PIA revit model. A friend told me this is because Navisworks uses a different algorithm and compresses these files so they are easy to navigate. Why can the complacent folks at Revit development take look at it and learn.
Reportedly Navisworks and others are not manipulating data when viewing the geometry so the "load" on those applications is much lighter compared with Revit own interface.
Native "64 bit" Revit is not far off in our future. So while it may be frustrating now, we will have the "barricade" removed to access extra RAM in the near future. Soon...not soon enough...but soon.
Not all of Revit's processes lend themselves to multi-threading. In the words of someone I trust on this matter, "multi-threading, unless done very well, would probably make Revit slower, not faster."
For the development team, Revit's performance remains a high priority at all times. Every release contains some measure of changes to improve peformance, some major, some minor.
Like auto racing where serious money is spent to gain a "hundredth of a second", Revit's teams is also focused on this issue.
Post a Comment