File Sizes

I have a drawing file in 2005 SP 5 that was getting very large, so I removed
about half of the sheets from it. The problem is that even though I removed
a lot of the sheets the file is still very large. Is there a simple way to
get solidworks to remove any unnecessary data and reduce the file? I was
able to fix a file that was derived from my original by doing a "Save-As",
but I would like to know if there is a better way.

 

That's one of the best and safest. The other that I use is EcoSqueeze. Not
officially condoned by SW, but I've never had any issue that I could tie to
using it.

WT

 

Does reducing the file size of assemblies and parts have any effect on
the load time/memory usage of solidworks, or does it just reduce
disk/vault storage space usage?

 

I don't know - I've never done any testing of that kind.

WT

 

The file size reductions (accomplished by "save as" or through the use
of file unfragmenter software) are only temporary.

I think the reductions are useful for cutting down on disk/vault
storage requirements and for the transfer of data across the internet,
for example; however, working to continually "compress" active files is
a waste of time from a SolidWorks performance standpoint.

Most of the reduction in file size, as far as I know, comes from the
elimination of the Object Linking and Embedding (OLE) overhead. Even
after being saved without the OLE "baggage", when files are next opened
and worked with in SolidWorks, the "bloat" returns.

My 2¢,

Per O. Hoel
____________________

 

By reducing the file size of one of my files (from 49 megs to 600k), it
greatly improved the time to load the drawing. That was the primary reason
why I want to reduce the file size. The bloat has not returned because the
file does not have the elements that caused it to get bloated in the first
place.

 

I did some quick tests some time ago that showed that reducing file size did
reduce our load times. I didn't think to check memory usage. I also tried
radically reducing file size by removing the Parasolid data with EcoSqueeze
and found that it took about the same amount of time to load the stripped
file as the file with Parasolid data. I never followed up on the preliminary
results because I didn't have time or the inclination to work out a solution
that would work with our PDM system.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

I may be being bloody stupid here!, lol, but if you draw a cube so that you
part or assembly is inside, this reduces the size, does it not?
Not ideal, but good for zipping files, just suppress the cube when you want
to use the part.

 

Hmmm, just did a smallish test on a part, and its associated assembly.
The part consists of essentially a length of perforated tubing. File-save
as brought it down to 4Mb from a whoppingly bloated 27, doing a cylindrical
extrude that covered everything brought file size down to 1.75Mb.

The associated assembly file before: 2.10 MB, file-save as: 2.30 MB, and
a cut-extrude assembly feature removing all material 67.5 KB ( a whopping
95+ % reduction in file size ).

I think it would be a pain to remember to unsupress features to work,
especially if it were a large assembly, but for file transfer the same 22Mb
(zipped ) file that I sent my var for trouble shooting shrunk to a 1.5Mb
file after a covering extrusion and zipping it. Thats pretty handy and
would have saved my having to FTP it to them due to e-mail limitations.

 

Why does drawing a cube or cylinder around the model reduce the file
size?

 

Because the bulk of the file bloat is two things,

1. Microsoft's file OLE fragmentation which is why "Save As" to a new
file name reduces the file size.

2. Solidworks stores the 3d parasolid body in the file so that the
viewer and eDrawings can view the model. Also, a solid of each
configuration is stored leading to even larger files as you add more
configs.

So in this case a solid body of a perforated screen contains alot of 3d
data where as a cube is simple.

 

Here is a Knowledge Base article I written on this subject.


The SolidWork's part file is broken up into 4 different parts; Header,
Instruction Set, Database, and the Visualization Data. The
Visualization data is used to provide the image you see on the monitor
and the preview image when you open the file. If you could limit the
amount of visible faces, edges and vertices of a part, you could
minimize the overall file size of the part. The visualization data
generally not needed for a file transfer through email.


One way to minimize visualization data is to extrude a dummy block that

encompasses the whole part. This breaks the visualization data down to
6 faces, 12 edges and 8 vertices. It is good practice to rename the
feature as "Delete Me" or enclose instructions in the email explaining
what feature to delete to bring back the original part.


Another way is to suppress the entire tree. You can accomplish this by
suppressing the base feature of the part. This will in turn suppress
the entire feature tree. Again it should be best practice to include
instructions in the email when using this practice.


Remember, there is visualization data for every configuration in the
part. The block method is ideal for parts where configurations are
used.

 

Wow, this is getting away from my original intent. I am working with a
drawing, not the part files.

What I had was a drawing file that was large, and it was so large that I
decided to split the information into 3 files with the hope of significantly
decreasing the file size. Since I did a save as for the files I split off,
the original file remained the same size, eventhough I deleted unwanted
sheets.

As far as I can see, SW only updates or adds information to file, but if
things are removed, it doesn't remvoe that data.

 

Yes, you're right. As Wayne said in the first reply, you can either use
"Save As" or EcoSqueeze to get the file size reduced. EcoSqueeze is nice
because you don't have to save the file to a new name and then back again.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

Gentlemen,
Zooming part, assy or drawing to "infinite" reduce visualization data
to nearly 0.
Another good thing is to change existing "standard" configurations into
"design table driven" configurations.

Regards,
SWPriest

 

Pointers to the old/deleted entity data are flagged for deletion it
sounds like, not the data deleted.
This is what ComputerVision's "PACK DBASE" command was
for ... it "repacked" the entity database.

If this was done each time an entity was deleted it would take
a LOT of time as each entity might point to other entities as
part of it's structure or be pointed to by others and everything
would have to be checked each time.
This also resequences the entity ID numbers (integers) so
that the now deleted entity numbers can be reused ... 1,2,3
instead of 1,,3 ..... which could matter a lot on 16 bit integer
systems with "larger" (entity count) parts.
Resequencing would change some of the entity ID integers
in cases where things had been deleted that were not the last
ones created.
MIPTRs (Master Index Pointers).

This applies only to the part database. The graphics file/subfile(s)
might be another matter (fewer relationships) but was often
recreated as well to speed things up after large changes IIRC.

 

Jason,
Are you the same Jason they worked for think3?

 

Are these related matters??

 

Yep, I was being stupid!, lol