Myth 2: Dwg files in families must be avoided
Some modeling guidelines recommend that you only use families that are native to Revit, preferably those you created yourself. Embedding of DWG blocks is almost frowned upon. Especially manufacturer families are often deemed to be hopelessly obsolete and contain errors. However, the purist approach of generating each family itself is usually discarded after some time. At the latest when it turns out that your designers are also only human after all, the generation of families massively ties up resources and in the end you still do quite well with the available content from trustworthy sources, even if a part of the available families cannot meet the claim to be free from DWG files.
About the performance of embedded DWG files
Embedded DWG files suffer essentially from the fact, that they are associated with one of the greatest deadly sins among Revit users: excessive use of embedded DWG drawings in Revit projects. It even gets worse if you "explode" these CAD models into individual objects. The ability to use DWG drawings as a "background layer" is undoubtedly an important building block for the transition from AutoCAD to Revit, e.g. in redevelopment projects. If the drawings are not linked but embedded and then not removed from the model views, performance is likely to suffer. When asked what problems there are with embedded DWG files in families, performance and memory requirements are often cited as arguments. But do DWG files in Revit families share these unsightly characteristics at all, which are rightly attributed to them at project level?
First some basics: Revit families carry a certain amount of data. The minimum size of empty family files is about 300-400 KB. The decisive factor now is the additional amount of data required to model the actual component and the effort required to display it. With a few exceptions, RFA files should never have to exceed the size of one megabyte. Due to the family-instance principle in Revit, however, the principle "families are expensive, instances are cheap" fortunately applies to the pure file size, which is why the file size of the project results as a mixed calculation of families and their instances. Even here, DWG families are no exception, as we would like to demonstrate in the following with easily comprehensible examples.
Many identical elements
The first experiment is as follows: In an otherwise empty Revit project, we successively copy many instances of a single DWG family (here a FKU90 fire damper from the Wildeboer catalog 06/2021) and log the required hard disk space with each doubling step, the required memory after opening the project as well as the time, that a view creation (3D without cutting area with hidden lines) requires in the detail levels coarse, medium and fine.
While the process of initially adding the family enlarges the project by about 140 kB, each additional instance in the project file is added with about 120 bytes, whereas it is processed with around 3 kB at runtime. This footprint naturally increases with each instance parameter that is created and filled, so that for real projects a slightly higher storage load per instance must be calculated. In terms of performance, the effort involved in generating a view develops asymptotically linear with the number of elements to be represented, which is expected. Now this constructive example is by no means representative for a real project. However, with this simple experiment it can still be shown impressively, that many instances of individual DWG families do not show any notable differences in resource utilization.
Many different elements
Now that there’s proof that it's not the number of elements but the number of families behind them, that affects the project size, let's take a second look at how memory usage changes depending on the number of individual DWG families in the project. With the LINEAR CAD browser we therefore add 256 randomly selected families from different manufacturers and product groups into an empty Revit project and log the storage loads.
It can be observed that the reserved main memory of the Revit process remains largely unchanged. Only from 64 different families or more in the project a slight increase occurs. As expected, the project size increases linearly with the number of families in the project, with the average memory requirement in the project being about 300 KB per family. The required memory, on the other hand, can be estimated at an average of about 1.2 MB per family in use. Most families are not used only once in the project. Therefore, we extend this experiment by successively doubling the 256 families as before and again observing the memory and the required processing capacity for view creation.
Even in this example, which is much closer to real projects in terms of structure, no performance disadvantage of the DWG families can be determined. The size of the model depends substantially on the number of elements and the contained information density, which makes it difficult to give general estimates. However, with an average number of repetitions of just under 75 KB on the storage, the average required capacity per instance is already significantly lower than usual rules of thumb, according to which the project size should not exceed about 100 KB per component. Not to mention that, in addition to the product families, many lightweight system elements for pipes, etc. are used. There is still enough space for additional alphanumeric information on the elements.