File Size Suggestion

[Eric Chase]

I'm trying a few different techniques to keep my file sizes smaller, so VWX doesn't eat up my RAM and bog down my machine. 

 

2021 MacBook Pr: Apple M1 Max, 64GB Memory

 

Reference Files: I've got a large event site with several areas, I thought I'd keep each area as a separate file and have them all reference into a Master File, which I'd use to make sheet layers, etc. but I'm not sure that this hasn't had the opposite affect and it's working even harder.

 

Document Scale: Does this affect file sizes? I generally default to 1/4" (1:96) but again I'm wondering if a different scale would be beneficial, or if it's irrelevant.

 

Would love some thoughts on the above.

 

[Pat Stanford]

Scale is irrelevant.  Layer Scale in VW is more like a "preset zoom".  You are always drawing everything at 1:1, but on layers of different scales you are just zoomed in or out more or less on the model.

[Jesse Cogswell]

When you reference files, you have the option of saving referenced data in the master file.  This has the benefit of maintaining the referenced viewport even if the reference link gets broken, but also means that all of the referenced resources are still being saved in the master file.  I suspect that is what is causing your issue.  If you go to the References tab of the Organization Window, you'll see a column named Save Cache.  In your instance, you want that to read "no" for each of your references.  If you see one marked "Yes", click on the reference, click the Edit button and deselect Save referenced cache to disk.

[Pat Stanford]

Are you sure @Jesse Cogswell?  Yes, not saving the cache will not import any unused resources from the file, but in order to process the file you still have to bring all of the drawing elements from the referenced file into memory.

 

I don't have any basis to say this for certain, but with large files I could see this at putting more memory pressure because those referenced items might have to be stored in memory instead of being written out to disk when not needed. Or maybe VW is smart enough to only read in the part of the referenced file it needs to minimize memory pressure.

 

🤷‍♂️

[Pat Stanford]

You can't Thumbs up both of us @Tom W.  One of us has to be wrong. 😉

 

But we are both trying to be helpful, so I guess it is ok.  👍

[Tom W.]

23 minutes ago, Pat Stanford said:

we are both trying to be helpful

 

Yes hence the thumbs ups! I have done a lot of referencing, both DLVPs + layer import, and haven't found it to markedly reduce file size. In fact on one project I think I completely ballsed it up by referencing the files in both directions + created an infinite loop of updating... I'm pretty sure I have tried both enabling + disabling Save Cache + it didn't make much difference but I am going to check next time to be sure... There is a lot of talk about using references to keep file size down so important to establish that it actually does what it says on the tin because it's a lot easier not to have references if you don't need them. But I would really like to think that they did work to keep things smaller as it feels like it should.

[Jesse Cogswell]

So I was curious about this and did a bit of an experiment this morning.

 

I have a file for one of the museums that I regularly do work for that served as a "master gallery plan" that I made back in 2019.  The file contains the full floor plan of the museum, built in 3D using the Vectorworks walls and doors, and six referenced files, one for each exhibit at the time.  These referenced files are from a range of designers, dating between 2009 and 2019, all with 3D elements modeled with a wide range of different approaches that ultimately affect file sizes (high-res textures, mesh objects, solids with various levels of "proper" construction, use of groups instead of symbols, etc).  I updated all of the references up to VW2022 from their original VW2019, and saved a version of the file with the references cached and one not cached and ran a variety of tests including changing views, changing layer visibility, and navigating in flyover view with Shaded rendering while keeping an eye on the memory and CPU usage in Task Manager.

 

Here are the results:

 

Cached:

• File Size: 358,469 KB
• Time to open: 0:15
• Time to switch from Plan to Isometric first time: 1:06
• Time to render Shaded from Wire-frame first time: 0:15
• Peak memory use: 13,264 MB
• Average CPU use when using flyover in Shaded: 17-20%

Non-Cached:

• File Size: 168,176 KB
• Time to open: 0:36
• Time to switch from Plan to Isometric first time: 1:09
• Time to render Shaded from Wire-frame first time: 0:15
• Peak memory use: 13,204 MB
• Average CPU use when using flyover in Shaded: 17-20%

I tested each drawing 3 times, fully closing Vectorworks between each test.  What does this tell us?  There's probably not much of a difference from a performance standpoint between caching and not caching your references.  The two biggest differences are between the master file size (which can be major when you start to factor in backups), and time to open (which can be major if VW continually crashes, though I've had relatively high luck with 2022 and 2023).

 

Anecdotally, back in 2017 I was working on a light plot with fairly complex 3D scenery that I initially imported directly into my lighting file.  I experienced crashes very regularly, and after getting frustrated having to reload for the umpteenth time, I finally just referenced in the set as a referenced viewport and removed the assets from the lighting drawing.  Not only did the drawing run a little faster, it started crashing only occasionally rather than often.  After that I made it my standard practice to reference scenery and exhibit drawings rather than importing directly with the added benefit that I no longer had to deal with another designer's class structure and assets cluttering up my drawing.

[Tom W.]

13 minutes ago, Jesse Cogswell said:

So I was curious about this and did a bit of an experiment this morning.

 

I have a file for one of the museums that I regularly do work for that served as a "master gallery plan" that I made back in 2019.  The file contains the full floor plan of the museum, built in 3D using the Vectorworks walls and doors, and six referenced files, one for each exhibit at the time.  These referenced files are from a range of designers, dating between 2009 and 2019, all with 3D elements modeled with a wide range of different approaches that ultimately affect file sizes (high-res textures, mesh objects, solids with various levels of "proper" construction, use of groups instead of symbols, etc).  I updated all of the references up to VW2022 from their original VW2019, and saved a version of the file with the references cached and one not cached and ran a variety of tests including changing views, changing layer visibility, and navigating in flyover view with Shaded rendering while keeping an eye on the memory and CPU usage in Task Manager.

 

Here are the results:

 

Cached:

• File Size: 358,469 KB
• Time to open: 0:15
• Time to switch from Plan to Isometric first time: 1:06
• Time to render Shaded from Wire-frame first time: 0:15
• Peak memory use: 13,264 MB
• Average CPU use when using flyover in Shaded: 17-20%

Non-Cached:

• File Size: 168,176 KB
• Time to open: 0:36
• Time to switch from Plan to Isometric first time: 1:09
• Time to render Shaded from Wire-frame first time: 0:15
• Peak memory use: 13,204 MB
• Average CPU use when using flyover in Shaded: 17-20%

I tested each drawing 3 times, fully closing Vectorworks between each test.  What does this tell us?  There's probably not much of a difference from a performance standpoint between caching and not caching your references.  The two biggest differences are between the master file size (which can be major when you start to factor in backups), and time to open (which can be major if VW continually crashes, though I've had relatively high luck with 2022 and 2023).

 

Anecdotally, back in 2017 I was working on a light plot with fairly complex 3D scenery that I initially imported directly into my lighting file.  I experienced crashes very regularly, and after getting frustrated having to reload for the umpteenth time, I finally just referenced in the set as a referenced viewport and removed the assets from the lighting drawing.  Not only did the drawing run a little faster, it started crashing only occasionally rather than often.  After that I made it my standard practice to reference scenery and exhibit drawings rather than importing directly with the added benefit that I no longer had to deal with another designer's class structure and assets cluttering up my drawing.

 

Thanks jesse Are you able to do a third test and import the referenced geometry into the target file + see what the file size is then?

 

 

[Jesse Cogswell]

Sure thing.  After deleting the references and having the assets imported, the final file size is 419,238 KB.  But now there's a ton of classes and layers that are all over the place, and my Resource Manager has exploded.

[Tom W.]

Thanks @Jesse Cogswell that's really useful to know! Seems like you've got things working exactly the way they should.

 

In contrast I have checked a project of mine from last year. I made some notes at the time. I had a main file with a site model in it then ten separate files containing detailed building models referenced into it via layer import referencing. The size of this main file was 1.49 GB. This is with Save referenced cache to disk disabled. At some point I created a new version of this file where I deleted all the references + imported all of the referenced geometry into the file + the file size only went up to 1.51 GB. I am still working on this file periodically + the size is currently 1.85 GB but it seems to operate fine...

[zoomer]

I also use reference caching.

I think that is no problem.

Otherwise VW would also load the REFs when opening the file and need the RAM.

At least when displayed.

 

I maybe renounce of caching SLVPs.

But I also think that will not really hurt.

The file size is huge but I expect VW to only put in RAM what is needed (?)

(Not sure what happens when you switch between all your SLVPs,

but if loaded, I think on Apple ARM these are things that should move into

swap memory on SSD ?)

[Eric Chase]

@Jesse Cogswell damn thanks for putting in that time. Really interesting. I'm going to do some digging, but I'm definitely in need of some tips on getting files sizes done on larger projects. I'm getting the old pinwheel of death just drawing a circle and putting a number inside it....I know some of this is just the size of the the program, it's beast of a program....but I also am certain I'm missing some good opportunities to lower files size.s

 

Thanks for all the replies everyone, very helpful.

Edited February 23, 2023 by Eric Chase

[EAlexander]

Use symbols as much as possible. 

 

Run the Purge command from time to time.  Unused resources still contribute to file size. 

 

Convert to generic solid what you can and never need to change. 

 

Restart machine daily. 

 

Basic stuff but it all helps.