Does the family make your models sluggish? Does changing parameters take obscenely long? (like, thirty seconds...). If not, who cares? ive got an elevator family thats 10MB, with a bunch of stuff nested in. It still performs better, responds quicker, and acts cleaner than the POS ones from manufacturers that are half the size.

Correlation between file size and performance doesnt always equal causation. It is true that screwed up files will typically bloat and get larger. But its not true that large content is always screwed up. I wouldnt pay attention to file size at all.

I know, but a 10MB elevator is something different from a 10MB clock.
Like I said, it responds fine (actually, to me it seems extremely fast given the file size but that could just be because I have a growling beast for a pc sitting below my desk which loves all these calculation stuff)

It's not the filesize that bugs me really. It's the fact that I can't seem to figure out where it's coming from. Like I said, there's a 4-5 times increase of the filesize in the host family compared to the accumulated filesizes of the components. But there isn't really anything in the host family.
The reason it concerns me is that I'm just starting a project where I'm supposed to create a failsave set of families (as far as that can be achieved). My take on it was using as much nested components as possible to create host families with only those parameters in them that may actually be edited by the users without the possibility of screwing up the family. But if that creates monstrocities in terms of filesize, I don't know if that's a smart thing to do.

I think the family maker should care about file size. An unusual large size perhaps is an indication that the methods used to create the family should be revised and replaced with more efficient methods. Take for example the 10 mb clock. It can be done with less than 0.4 mb by other methods.

That doesnt mean its better, because its 0.4 MB. Thats the problem. The Model Style Guide spews that same bunch of hoopla, too. We built our door families to do exactly what they needed to do ARCHITECTURALLY, and i am certain they are built as efficient as they can. Its bigger than "what they say" in the Model Style Guide. Does that make it a bad door? No.

Im not saying a clock SHOULD be 10MB, but im saying... If it is causing issues, id revisit it. If the issue is that its large, id ignore it.

Families DO get larger than the accumated size of their Nested components (assuming unshared... If theyre shared theyre not even all there all of the time), but i wouldnt worry about it.

Now, im curious about the need for a parametric clock that has enough parametrics to change the time on it, but ill assume you built it because you need it, lol.

Perhaps it can, but that's not my question. I'm wondering what's happening here. Is this a given drawback on using nested components? I wouldn't mind if it were 3-4mb. That would be expected given the filesize of the nested components.

I didn't create the clock this way because it's the best way to do this in this instance. It was an excersize for an upcoming job where I am planning to use nested components extensively to create a library of complex components. Mixing business with pleasure sort of speak.
For this job I need to create a relatively small library using a large amount of parts. Also the host families need to have as little amount of parameters as possible to keep the usage simple.

So for that job using nested components is the only way I see fit to meet all design criteria. But this excersize gives me the idea that this method could create huge families, with accordingly large project files. So do I need to talk to my client about this?

Nested components are NOT a bad thing, certifiably.

What makes nested families PERFORMANCE detriments is the LEVELS that you nest. For instance, 20 families nested in to one parent, and using a FT parameter to pick between them, thats one level. Then having more components nested IN to those 20, thats a second level. it just makes swapping slower, and changing parameter values slower. However, its STILL not a bad idea, as its the only way to achieve certain things in Revit.

I have some families than are nested 5 levels deep. Parent > Nested1 > Nested2 > Nested3 > Nested4 > Nested 5. They work flawlessly, and quickly, in the project.

If the ponit of the "exercise" is to validate that Nested Components wont kill a job, rest assured: That alone wont kill a job. EVERY one of our pieces of content has at least one or two nested components in it.

Well, it's not just the nested components. I almost do everything with those (that accounts for the preoccupation, I tend to forget that some tasks are also and more easily done with live components).
It's more the complexity of the nested components and the linking of parameters a few levels down that concerns me. For instance: the material parameters link down 2 levels. Same goes for the sizing parameters for the pointers, and the FT-parameters (although I didn't check if that actually works). Does this hurt?
Also the visibility parameters in the components. Although this "excersize" is a little over the top, I will probably use those to some extent. Not necessarily visibility parameters but if not those there will be formula driven angles or dimensions that are linked in. I'm just trying to figure out on which part I have to be a little careful to keep filesizes to a minimum.

They wont hurt anything. I have plenty of stuff nested two and three levels deep. All that it does, is make it so they regenerate a tiny bit slower, but its still completely worth the gain, and in most cases, isnt causing an ill effect on performance.

All of our parametric radial arrays go down 5 levels, and they all have parameters that link up the entire 5 levels. Our basic parametric round table with chairs is that way. It performs like a champ.

The ONLY time i saw it as an issue, was in R2008, prior to reporting parameters. I was doing a project that had Armstrong Serpentina ceilings lined up in rows of twenty. I nested them in to a Line Based family, and there were parameters with the trig formulas in them to switch between the upside down or regular, and every size variation they made in all the series of serpentinas. There were a LOT of formulas, since Reporting parameters werent there. Changing the entire rwo from one type to the next was a simple parameter flip, but it took a few minutes to regenerate.

Slower than swapping twenty individual families types? Sure. But not when you consider placing them all, heights, etc. Even then, it was still the way to go.

EDIT: And again, id be focusing on PERFORMANCE. Not keeping file size to a minimum, but thats just my opinion.

Martijn - the size of your clock doesnt sound right to me either.
If I have a look at my doors which have unshared nested components, more and larger than your clock (say my cavity sliding door panel/swing/pelmet/handle/jamb/architrave/cavity!) it sits at about 1Mb - they also have nested components nested alot further than 2 levels deep....have you tried loading the clock into a project and then through the project browser doing a "save" and seeing if that makes a difference?

For me this seems to lower the file size the most (but then if you do anything to the family, it jumps up again)

I also agree completely with Aaron - when I first made my doors I was horrified that some were over 1Mb, but soon realised that was just how it is and the functionalty I required was 100 times more important