I know when to use either one, they are both great. But I was under the impression that a component file is smaller than the same file made it as a group. Nope, a component is bigger file than the same file as a group.
Maybe in this regard, a component when copied several times is smaller than the same file copied as a group.
Any opinion?
Thank you.
It’s interesting that you bring this up. I was just experimenting.
Here’s a screen shot from File Explorer. The first file is a single component of the pin you can see in the other screen shots. The second two entries are obviously 100 instance or the pin as a component and as a group.
For my work I find that groups provide no benefits over components and so I only use components. Of course some people prefer only groups and SketchUp will let you work whichever way you like.
There are many other features of components that groups don’t have that for me are more compelling reasons than file size to use them exclusively.
@DaveR that’s interesting. I thought that groups and components shared most of their implementation but components have a few attributes that groups do not (such as the name of the file they were saved to or loaded from, and advanced attributes). So I thought a model that differed only in using components vs equivalent groups would be slightly larger. Your results show a case that is the opposite! I’m at a loss as to why… Could it have something to do with the specific way you built these models, e.g. starting with components and converting them to groups (or the opposite)?
@DaveR Would you post the single pin? I’d like to duplicate your experiment and add 1 more case: Single pin component with 99 copies created dynamically!
@slbaumgartner Under the hood, groups are special cases of components. Both have both definitions and instances. For components, until/unless an instance is made unique, they share a single definition and each instance is just a transformation of the definition - and storage of the transformation is far smaller than storage of the full geometry. For groups, each copy stores a complete set of the geometry. Thus an otherwise identical collection of multiple copies of groups will take more storage space than the equivalent collection of multiple instances of a single component.
You can do it with any component.
Wanted to use yours so that my file sizes come out roughly the same as yours!
I don’t know. I created the pin as a component (I never create groups first before converting to components) and to make the group, I exploded the component (and purged it from the file) and created a group with the selected geometry.
I’ve done this sort of thing for many years for things like screw threads on vises and dentil moldings to help keep file size down. It also helps with more complex parts that are symmetrical. Obviously it doesn’t do anything to reduce entity counts but it keeps file size down.
The threads on these vise screws for example are made up of multiple instances of a component representing a single turn. That way of constructing the threads makes it a simple matter to adjust the length of the screw for different applications. I could easily make a lead screw for a CNC machine, for example by making additional copies of the thread component.
The jaws on this vise are drawn as halves, copied and flipped. I didn’t need to show the screw threads with this one so there aren’t any but it would be simple enough to put the screw out of another vise and put it in this one.
Here’s another comparison. Well, a single copy of the model versus 100 copies.
Sorry, that is not necessarily true! If you create copies of a Group using the Move tool or cut and paste, all the copies share the same ComponentDefinition. You can see this in the Entity Info window where it says “Group (n in model)” just like a Component. Only when you edit a copy is it split off from the share by getting a clone of the ComponentDefinition. This “lazy unique” is an optimization to reduce the memory used by identical copies of a Group.
<Smacks self on head>
I’d forgotten about that! And given my (erroneous) statement, the 100 group file should be roughly 100x the size of the 100 component file!
Now I’m wondering what is the (an) explanation for the 100 group file being (roughly) 3 times the size of the 100 component file?
Here are my results:
Things I find interesting:
Notes: I applied NO materials and didn’t “knurl” the nob (I can’t tell from @DaveR’s pics if the darker appearance of the knob is extra geometry or an applied texture)
It’s just a medium gray color. No texture. But it was the same in all three examples.
Definitely something odd going on. I tried duplicating the process @DaveR described and this is what I got:
I don’t know what to tell you Steve. I haven’t done anything special. I just made a component and for the groups, I just exploded the component, created a group from the selected geometry and then purged the unused component(s).
Ignoring file size differences, there’s enough advantages to using components over groups for me to stick with my workflow of using only components. And I’ve never seen any downside to it so I’ll continue doing the same.
I also use components almost exclusively, for all the reasons you give. I’d always believed they carried a slightly greater overhead compared to groups, but that their advantages more than overweighed it for the kinds of things I do.
I just like to understand the nuts-n-bolts inside a SketchUp model and in this example I can’t explain what happened in your sample vs mine.
All the posts are interesting. Besides the fact that we can have small file size when copying a component, and in agreement with slbaumgartner, we, who like SketchUp want to understand the nuts-n-bolts of this great program.
Thank you guys!!
Each component has a thumbnail image. I’, not sure but I’d suspect it is stored in the file, making it larger. Could also be generated on the fly when the Component panel is opened.
Regarding components lowering the file size, this isn’t the whole truth. Re-using the same definition again and again lower the file size. Groups do re-use the same definition when copied, until you start editing one of them. In this respect there is nothing magical about components making the file size smaller.
As Julia mentioned thumbnail images, I tested exporting the thumbnail as png.
The default was a 256x256 pixel 8K png file.
It may also be that for components, the behavioral properties are initialized, but may not be for groups. (Just a guess though as these behavior properties cannot be accessed for groups via the GUI, but can be via Ruby.)
Still 59 times is significant. It just indicates that the SKP format is binary and using some internal compression of it’s data structures. Also, as the entities data structure (database) is only 1 of it’s internal data structures (it has others for materials, layers, components, classifications, etc., each with some minimum overhead,) … so, adding data to only 1 internal database should not be expected to multiple the whole by an exact amount or multiplier.
So, the 100x is a false assumption, that disproved should lead to better understanding. (Ie, meaning that the making of an assumption, then testing it, is part of the scientific method.)
As I mentioned in some other DC threads yesterday, the DC engine always writes any DC attributes into the group instance’s DC dictionary (and looks for them there,) but uses a component’s definition DC attributes unless the component instance has differing attribute values.
So, for simple DC components, the instance DC dictionary will have only a few attributes such as the DC class version, and will use it’s definitions attributes unless they need to be overridden (by an instance DC attribute.)
Attribute dictionaries are text data with text keys and can add up quickly to bloat file size especially when these dictionaries are attached to objects in the entities collection (such as with DC group instances.)
Why did the DC authors treat DC groups this way ? I think because it allows for the group instances unique attribute set to be copied to any new group definition, should a “uniquifying” operation be triggered.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.
