Really slow family

[haydenwse]

I have a detail family that is made up of lines with yes/no visibility parameters to make different elements show in my documents.  This family is very handy but is SOOO SLOW!

My workstation is a very fast i7 with 32 GB ram and an SSD and will start Revit and open my 200 MB project in 10 to 20 seconds.  The problem is that takes several minutes to change from one type to another in this family. 

Does anyone have any idea why this family is so slow and what can be done to make it faster to use? 

[MKFreiert]

without looking at some how you've built the formulas driving the family, no. in general, the more things that revit has to look at in order to determine what happens to a family the longer it will take. if you have a lot of nested if statements that need to be resolved or a lot of visibility settings that it needs to sort through it'll increase regeneration time.

getting a complex family to do what you want isn't too bad, getting it to do so efficiently can be a whole nother can of bees.

[haydenwse]

This family is very simple with no equations or logic statements.  It is just lines that make up 5 different shapes which have been made into groups so that I can edit them when needed.  I have the lines for each type with a yes/no visability parameters.

The file size is about 2 MB and it will take as much as 4 to 5 minutes to change from one type to another within this file.  That is on a computer that can open a 200 MB project in less than 30 seconds.

I have included a screen shot of this family structure.

[Rave.Tam]

I ran into a few cases where grouping causes the family to render very slow when moved.

Try ungroup it and see if it's the problem.

[MKFreiert]

I'm going to concur, groups are (generally) bad in families, things start to get overly complex as far as how revit thinks about things.

For your family, if i'm understanding what you're doing, I would temproary hide all but one group (say group "a") ungroup it, select all of those lines, set their visibility, unhide all, hide lines, hide all but one group ("b"  and repeat.    While it's easier to manipulate them as a group, once the family is live, it's an added level of compliation that's not needed.  The other option is to turn each group into a sub-family, which works much better than grouping.

If you go with the first method, DO save a still grouped version, so that you can edit things more easily later on.  your live family does not have to be th same version as the one you use to build the family.

[haydenwse · Accepted solution]

Thanks for the replies.

On this family, ungrouping creates an uneditable mess with multiple lines in the same location and different visibility settings.

I stumbled on a good work-around.  I inserted the family into a new detail family and made copies for each type.  Then I set the visibility to a yes/no and assigned that to a type in the new family. 

With the new family I can change type in my project instantly so it solves the problem.  I can also go back and edit the groups in the original family and reload to the new one.  This is still painfully slow but I do not need to do it often,

[MKFreiert]

so, my second suggestion then. 😉

[haydenwse]

Not quite.  I inserted the original family as a nested family with its 8 types made up of several groups each into the new family.  I then duplicated the y/n parameters and the family types in the new one and made copies of each type and assigned the appropriate vis parameter.

So what I did was add one more level of complexity but the result was that it is now very useable.  Editing is still slow but I don't need to do that very much.

[MKFreiert]

so, you nested the family, and left the groups intact but as types already generated, and still in groups?

it's interesting to me that your solution doesn't result in similar problems. i was thinking more have each yes/no group as a discrete sub family nested into the insertion family.

[haydenwse]

I was surprised that it worked as well.  I thought that I would need to make each one a separate nested family but it didn't turn out that way. The groups did not come through as groups from the nested family. 

Each type is made up of several groups and the appearance is controlled by the y/n.  If you look at the screen shot of the family you will see multiple components.  One type might have the right side, the next will add the left side and a third will add the top.  They re controlled by checking the appropriate y/n.  My nesting the family I eliminated the groups but preserved the the types.

I have created a screen shot that shows the project with family types, the new family (#2) and nested family (#1).

[MKFreiert]

i'm going to guess that revit is in effect caching the different types in the nested family, and not regenerating them on the fly as it normally would. while this should be fine, you may find that this can cause some unexpected behavior down the road. I've run into a few families that were fine 95% of the time, but went a lil wonky that last 5% with some absurd series of renaming and reloading necessary to get them to behave. since it's just details, i wouldn't anticipate that sort of fun.