Is 2k4 bloatware?

Hi all,

I have recently opened an old assembly developed in 2k1 in 2k4 and the file size has jumped from 1.9meg to over 10meg! with few changes to the assembly! What is going on here or could I have a corruption? Is there a way of checking the database? Any one else seen this 5x jump in size for no apparent reason?

TIA,

JAG

Reply to
JAG
Loading thread data ...

One reason that may not be apparent is that 04 can load subassemblies lightweight. In fact, I can't remember if 01 could even save parts lightweight. Anyway, in order to do that, display info has to be stored in the files. This is just one possible explanation, I don't know if its actually correct. Do make sure you're not saving eDrawings data in your files. You'll find that in the SaveAs dialog box, IIRC. Somebody jump in and slap me if I'm wrong.

What I'm trying to illustrate is that the storage space needed by new features is increasing faster than any efforts to store the data more efficiently (if such an effort exists.) Does that make it bloatware? I dunno. It's your call. If you don't need the new features, don't use it. SW04 does require a more powerful system than 01, but that's the way it goes. Hopefully that extra power is translated into more work getting done for you by the software.

If the increased file sizes are a significant problem, look into using EcoSqueeze to crush them down smaller than you've ever seen them, until you can get enough storage space to handle the files. SW does not recommend or support the use of tools like EcoSqueeze or Unfrag, but nobody has reported a problem with either in this forum.

Reply to
Dale Dunn

In 2003, it lived in "Tools/Options/System Options/General

Reply to
Andrew Troup

Reply to
Sporkman

Most of the files size increase I've run across (and yes, it's huge) IS apparent if you look at rebuild times when working on files with long feature trees. Here's the chronology as I know it... \

2001+ and before - when we opened a part and rolled it back to work on it, the entire part needed to be rebuilt from the top back down to the rollback bar. This was a massive drain on productivity - I remember trying to do anything to avoid rolling back on long parts because I couldn't stand waiting forever for the part to rebuild. Also, crashes in a rolled back part hit you twice - you lost the part, and you had to go through the stinking rebuild again

In 2003, SWx added a neat new trick. When you first opened a part and rolled it back, the part still rebuilt from the top back down to the rollback bar. But while it rebuilt, after every few features SWx would squirrel away in memory a parasolid 'snapshot' of the part. Every other time you rolled back after that, SWx wouldn't have to calculate every single feature anymore - only the space between the rollback bar and the closest valid 'snapshot'.

Enter the user base. If you were to look back at the newsgroup, there were complaints about the rebuild times - why does my part take so long to rebuild the first time I open and roll it back when it is so fast the rest of the time? Unless you put it in the context of 2001+ or earlier versions, SWx looked like it was inefficient when actually it was way faster to work on! Well, SWx listened to its customers complaints about that first rebuild time, and made another fix.

In 2004, there is no major rebuild when you first open a 2004 part because all of those snapshots are saved with the file, making for the larger file size. The theory is that Hardrive space is cheap, so why not satisfy the customers desire for working faster? With all of the parasolid snapshots saved in the file, we don't have to calculate much at all when we first roll back a part. Of course, older part files don't have all the extra parasolid data, so we still have to rebuild them when they are first opened and worked on. When you save it in 2004, all of the stuff gets added and you will see the huge jump in file size.

Of course, this bigger file size causes problems when you look outside of just the space on the hard drive. Network traffic goes up, and emailing files becomes a real dodgy thing because of email limits (this is why ecosqueeze added the new parasolid removal options to its terrific product)

The user advantage to all of this is pretty minor imo unless you are like me and work on files with hundreds and hundreds of features. On a part with maybe a total of 4 second rebuild time, I'd rather have the smaller file. But when working on the big parts, I don't mind that my file in now 56Meg because I can work on it so much faster and not suffer the three minute rebuild time every time I open and roll back to make an edit. On the other hand, when the part is done and ready for delivery, we don't need all those intermediate steps anymore. This snapshot deal needs improvements - no saved snapshots on small parts, and an option to save big parts for delivery and archiving without the now-unnecessary snapshots.

Hope this helps- Ed

*In 2003 there were also complaints about the corresponding memory bloat (those snapshots took up space after all) - remember how in the old days we could use SWX on 256-512Meg and be OK? I wouldn't even touch SWx with under a Gig today.
Reply to
Edward T Eaton

This isn't really what you asked, but on the topic of "bloatware"...

I heard from a SW world attendee that SW2004 has 30% more lines of code than

2003. This was apparently cited as an advance.

Wondered why it took so much longer to start up on my old workstation.

Richard M ______________

Reply to
Richard

I forgot about the rollback changes. But doesn't the "save tesselation data" option in 04 relieve most of this? I've not tested it much, so I'm not sure how much space it would save on really big part files.

Reply to
Dale Dunn

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.