Central file bloat

[aireq303]

The central file for a project I'm working on has reached over 320 mb, which obviously causes some issues with loading and syncing even if everyone is on 64 bit machines with lots of RAM.

Last night when troubleshooting some syncing issues I tried detaching from central and saving a new central file. The new central file, however, was only 125 mb.

Can someone tell me what's going on here exactly? I like Revit, but when I see things like this I start to feel like it's the ******* stepchild of AutoCad and MS Access.

I'm thinking about making it a regular part of our workflow to save a new central file every friday night. Other then invalidating local files that weren't synced before the weekend, is there anything else I should be considering before doing this?


Eric

[twiceroadsfool]

Size does not necessarily correlate to performance, period.

If there are issues with loading and synching, i would suggest checking the Review Warnings dialogue. How many warnings are in there? A simple *butt dyno* is that at or over about 300, people start to get the warning "Save to central has not completed due to problems while reloading latest. The error has now been reconciled. Please try again." Warnings = file bloat, and sluggish performance.

When you make a new central file, it compacts the file automatically. That is the only reason its smaller when you DFC and Save as. That isnt making it perform any better.

Also, for what its worth, your users should get a new local file EVERY MORNING, at least. Everyone here just leaves the "Make new local" button checked, and gets a new local everytime they open the file, so it shouldnt be an issue.

But "syncing issues" dont sound like they are file SIZE related, so much as the file having some issues that need to be resolved.

[aireq303]

Looks like there are 28 warnings. We do have people create a new local every morning. What does compact actually do? Does it remove unneeded information from the file, or is it just a zip style compression? I remember hearing that compacting was bad because it meant that the file had to both be transferred of the network and uncompacted before it would fully open.

[twiceroadsfool]

Im not sure exactly how it compacts, though i know it doesnt remove much (if anything) from the project. But again, file size doesnt always dictate performance issues.

What sort of "synching and loading issues" are you trying to circumvent?

28 warnings certainly arent the problem, but there are a lot of things that could contribute to synching and loading problems. How many people are in the file each day? How big (geographically) is the project?

[aireq303]

...ok well there are 28 types of warnings, but if I export a report there are 1967 errors total.

Here's a link to (http://dl.dropbox.com/u/113068/error%20report.html) a posted copy of the error report.

It's working, but overall very slow to load or sync. There are at most 5 people working on this file at any one time. Although there are other linked files for this project that other people are also working on.

I'm going to try to sort through the warnings now.

[patricks]

Definitely try to reduce/fix the warnings. I would also suggest purging all unused elements from the file. If you're pretty far along in the project, that should reduce the file size drastically, even from the 125 MB you saw earlier.

[Steve_Stafford]

You can read this about Compacting a Database (http://www.databasedev.co.uk/compacting-and-repairing-ms-access.html) as it applies to MS Access. As an example, when you delete elements the space their records took up in the Revit database is not necessarily released. There is a distinct possibility that you will use "Undo" which means that Revit may have to restore it. Imagine when you delete something Revit is thinking, "Yeah sure you are...!"

Using the Compact option is telling Revit to "clean-up" such things to reduce the file size. It should not be confused with Purge Unused which does remove "active/present but unused" elements from the database. Essentially "Compact" is only acting on records that are "dead" to Revit and have already been "hidden" from us at some time in the past.

[aireq303]

So is it a good idea to compact the central file on a regular basis? I've always thought that doing so would increase load time because it would have to un compact the file? Is Revit compacting like MS Access compacting?

[cliff collins]

1. Compact when Synchronizing--every time--all users.

2. Open the Central file in the morning, before anyone else opens it--and check the Audit
box. This will go thru the file and discover any conflicts/errors,etc.

3. Purge unused. Check with PA/BIM Mgr. before doing this.

4. Break it up into Linked Files. Do you have all the Interior Finishes in the Arch. model?
If so--separate into Shell/Core and ID models.

cheers...............

[twiceroadsfool]

...ok well there are 28 types of warnings, but if I export a report there are 1967 errors total.

Here's a link to (http://dl.dropbox.com/u/113068/error%20report.html) a posted copy of the error report.

It's working, but overall very slow to load or sync. There are at most 5 people working on this file at any one time. Although there are other linked files for this project that other people are also working on.

I'm going to try to sort through the warnings now.

Bingo. Are you guys getting messages during save that errors have occurred during reload latest? Those types of things, as well as major slowdown and performance lag... Can be associated to a high warning count. Spend a couple of days cleaning them out. Ill bet once youre sub-300 warnings, the issues with loading and syncing will disappear.

[twiceroadsfool]

1. Compact when Synchronizing--every time--all users.

Sorry, i have to disagree. Its slower, and it has almost no ROI for the users during the day. Is has less than almost none, considering how long it takes, and the fact that with other users in there, it doesnt always even compact.


2. Open the Central file in the morning, before anyone else opens it--and check the Audit
box. This will go thru the file and discover any conflicts/errors,etc.

I do this once a week, but again... its splitting hairs in a project with 1900 warnings in it.


3. Purge unused. Check with PA/BIM Mgr. before doing this.

Definetely check with someone, especially if the file isnt heavily in to CD's. If you Purge Unused, and you havent started detailing, youre going to get ri of whatever is in the file already (from the template) that is used for detailing.

In our office, that button is 100% off limits to everyone besides the BIM manager.



4. Break it up into Linked Files. Do you have all the Interior Finishes in the Arch. model?
If so--separate into Shell/Core and ID models.

cheers...............

Im not singling out youyr response, per se... And im normally a fan of linked files. But if there is that much stuff gone wrong in that file, all thats going to happen when he makes them links, is the mess will be spread around.

Warnings have a major impact on performance, AND an effect on file size. In my blog a long time ago i kept track, on a project that had about 2000 warnings, while i cleaned them out. The file got rediculously faster, and it also dropped something like 70 MB in the process.

If it were me... And its not, hehe, but if it was... I wouldnt try anything else until that file has the vast majority of those warnings cleared out.

[aireq303]

Are there specific types of warnings that cause the larges performance hit? Or on the other hand are there types or warnings that we can safely ignore? I'm trying to optimize my time going through them.

[nancy.mcclure]

In my experience, the number of unique warning types may be more problematic than a large number of the same warning - ie: 24 "objects overlap" warnings is less of an issue than several diverse warnings of more significant impact: Stair/Ramp warnings, Room/Area boundary warnings are all big issues - because they are going to constantly trigger a recalculation that hits a snag that generates the error.

[troberts]

Also, for what its worth, your users should get a new local file EVERY MORNING, at least. Everyone here just leaves the "Make new local" button checked, and gets a new local everytime they open the file, so it shouldn't be an issue.
.

Okay, I must be missing something. Tell me about this "Make new local" button, please.
We have not been doing that, but so far, we have not had any problems.

Thanks, Tim

[twiceroadsfool]

In 2010, when you go to Open a file that is workshared, it automatically creates a new Local File everytime you open the file, if you open it from the Central.

In 2009, you either make a new local every day yourself, or you use one of the apps people have built to do it. You may not have experienced problems without it, but some people have.

[dmoodydesign]

Sorry, i have to disagree. Its slower, and it has almost no ROI for the users during the day. Is has less than almost none, considering how long it takes, and the fact that with other users in there, it doesnt always even compact.


I do this once a week, but again... its splitting hairs in a project with 1900 warnings in it.



To quote a recent post on compacting from the factory blog:

"Compact File

This reduces file sizes when saving workset-enabled files. Revit writes elements to the existing files in a way that increases the speed of the save yet can cause files to grow in size. This option rewrites the entire file during the save removing all unneeded information. This is something you may wish to do as periodic maintenance or just check when you make a new central file. It does cause the SaveAs to take longer than it would otherwise but makes a smaller file."

Read it all here:

http://insidethefactory.typepad.com/my_weblog/2010/01/save-options.html

[Imwezal]

aireq303, I read a forum here that might help you out on your error that says "Elements have duplicate 'Type Mark' values."
"Is it possible to not have both people placing the same types of families? Maybe one works on lighting layout while another does floor finishes or starts elevations and sections. In my experience Revit has always been frustating to work with when multiple people are doing the same type of work. Although it wasn't even possible back in the AutoCAD world.
If you must both work on placing lights then here is something that just came to mind. Decide ahead of time what series on lights you will each place. For example, say 200 lights need placed and in your area of the building all the lights will be 100's and she will be placing all the 200's. Both of you place your first light and go into the properties and change the Mark value to 100 and 200 respectively. Now continue placing lights and they should be given sequentially increasing Mark values based on the first one each of you placed and changed, so the next one you place will be automatically given the Mark value 101 and hers will be 201 and thus eliminating the Duplicate Mark error when STC is done."
http://forums.augi.com/showthread.php?t=113607&highlight=Elements+have+duplicate+%27Type+Mark%27+values.
hope it helps

[patricks]

To quote a recent post on compacting from the factory blog:

"Compact File

This reduces file sizes when saving workset-enabled files. Revit writes elements to the existing files in a way that increases the speed of the save yet can cause files to grow in size. This option rewrites the entire file during the save removing all unneeded information. This is something you may wish to do as periodic maintenance or just check when you make a new central file. It does cause the SaveAs to take longer than it would otherwise but makes a smaller file."

Read it all here:

http://insidethefactory.typepad.com/my_weblog/2010/01/save-options.html

Compact File is also available for non-workset files. Just do a Save As and click the Options button to turn on that option before saving.