Understanding what contributes to Archicad file size

This post was created by Jared Banks in 2014

This post is a follow up to two blog posts, one new and one old. In mid-May I shared a post on BIM Engine on what causes files to get slow and crash.I wrote the other post back in 2012 on why PDFs might be large. Read that one here. The image I used in that post came from a discussion among Beta testers about large PDFs—when we were all Beta testing Archicad 16! Such a long, long time ago. It’s worth noting (and we’ll revisit this later when Archicad 18 is officially out), that the PDF advancements in Archicad 18 include better (actual) control of PDF output size based on image resolution and compression. This means that if we export large PDFs we have more options than just deleting the fills that are making the PDF balloon in size.

Make sure to read the comments that go along with both posts. Many big names in the Archicad community add some amazing additional advice and thoughts. I always know I’ve picked a good topic when the list of names in the comment section of a post include the people commenting on those two posts. As you read through the comments on both PDF bloat and file slowness, you’ll notice that the topic of what makes files big comes up again and again. This is a topic that is also perennially on the ArchiCAD-Talk Forum and elsewhere (exhibit A and B and C).

Large Archicad Files: what causes file bloat?

Managing file size and preventing file bloat is ultimately about good BIM management; and not letting any specific area of the file get away from you. I have seen many Archicad users get in the habit of dragging unused or unneeded objects to the side rather than deleting them. A cluttered model is going to increase file size more than just the necessary elements. Likewise many BIM managers like to overpopulate their template with standard objects that could be better stored in Favorites rather than left floating in a plan view or Worksheet (I have been guilty of that in the past). So while of course clean and simple is going to yield a smaller file than messy and cluttered (and yes sometimes it makes sense to store bits of model off to the side), are there any modeling and file management decisions that affect file size more than others? If you read through all the comment threads and forum posts I mentioned above, the list of culprits is long and varied: number of layouts, embedded library content, lines and fills, etc. But how much do each of these actually contribute to file size? Let’s find out—in a semi-scientific manner.

Your File is So Fat it needs its own Hard Drive

I took an average template, which was 4.2MB, and ran some tests. The template I used was already pretty stripped down as there were no “standard details” or Worksheets with instruction manuals or a populated model view with a kit of parts for the modelers to pull from. The test was to take this 4.2MB template and add or subtract to see the effect on .pln file size. For each test I reverted back to the original clean 4.2MB file. Some of the results are a little surprising.

Element Added or Subtracted From Template	File Size
None: original template	4.2 MB
Lines Added: 25,344 dashed lines 10’ long	7.7 MB
Columns Added: 25,344 6”x6”x9’	8.2 MB
Walls Added: 25,344 9’ tall 6 1/2″ wide walls with a three skin composite structure	11.4 MB
Fills Added: 25,344 3’x3’ “Brick Common” fills	7.1 MB
GDL Objects Placed: 25,344 WC 17 (toilet) placed	11.4 MB
Detail Markers Added: 150 Source Markers	6.4 MB
Detail Markers Added: 600 Linked Markers	6.2 MB
Section Markers Added: 150 Markers	6.1 MB
Elevation Markers Added: 150 Markers	6.3 MB
Additional Layout Sheets: 150 Additional Sheets Added to the Layout Book	6.2 MB
Library Abuse: 150 “Custom” Cabinets Saved to the Embedded Library	6.2 MB
Purge Attributes: 300+ Unused Attributes Purged from Attribute Manager	3.8 MB
Layouts Placed on Sheets: 150 Blank Plan Views Placed on a Sheet	5.2 MB
Extra Stories: 150 Additional Stories Added to the Project	4.7 MB
All of the Above (except the purged attributes)	33.5 MB

Now obviously some of these are apples and oranges for comparison, and there are quite a few things that were not checked for their effect on file size. I didn’t use the constant “25,344” for all tests. It was convenient for arraying objects, walls, lines, etc., not so convenient for adding stories, layouts, markers, etc. But even with the varied values I think we can draw some valuable conclusions.

Purging the Attribute Manager, unless it is really abused to begin with, is not a great file size reducer. Getting rid of nearly all the Attributes only decreased the template size by less than 500 KB. And as was discussed at length in the comments here, aggressive Attribute purging is a dangerous move if done blindly.

Markers of all types, linked or source, do not kill file size—if they contain no elements (more on that in a moment). Objects stored in the embedded library but not placed in the file have no more effect on file size than blank source markers. 3D elements and Objects generally affect file size significantly more than 2D elements. A wall with a simple Composite applied to it can increase file size just as much as a GDL object with a relatively low polygon count (the typical toilet in this case). That being said, I noticed the file was sluggish with 25k toilets but did not even flinch with 25k walls on a single plan view. What is perhaps most interesting though is that it took 25,000+ walls to increase the file size by 7 MB. So an individual wall is pretty negligible on file size or performance.

In a typical Archicad file you won’t have 25,000 elements. You’ll have a few hundred or thousand. For example, a current project of mine ready to go to permit has about 200 walls, 800 other 3D elements total (which includes completely modeled structural) and 7,000 2D elements (which includes dimensions, text, labels, markers, etc.). Although 5,000 of those 2D elements come from two PDFs I exploded in Archicad 18 and brought backwards into Archicad 17.

Even with over 150,000 2D, 3D Objects, Markers, Drawings, Stories, Layouts and placed Views, an Archicad file still doesn’t get absurdly large; all that is only 33.5 MB.

All the tests above look at elements in isolation. X number of Y. But in a real Archicad file, things interact and connect. So while you’ll have far fewer elements than I tested above, those elements will show up in elevations and sections, they’ll have SEOs applied to them, they’ll appear in sheets, etc. Thus we need to look at not just how many Ys there are, but how many times X has been done to Y. It is the links, operations, and connections added to a file that matter. I did another test that supports this concept. Here’s some data:

Windows, Walls, and Elevations Test	File Size
None: original template	2.6 MB
100 walls, each with 10 windows (so 1,000 windows total)	4.3 MB
200 walls, each with 10 windows (so 2,000 windows total)	4.8 MB
200 walls + 2,000 Windows, all shown in one elevation	5.8 MB
200 walls + 2,000 Windows, all shown in two elevations	6.7 MB

Adding more elements (walls and windows) had less affect on file size than showing those elements in a section. Interesting. Adding lots and lots of unnecessary section and elevation markers can quickly increase file size. Remember this the next time you need a working section: do you already have one you can use? Or can you delete it after you’re done with it? As a fun aside: showing all the elements in the first elevation took a good amount of time—enough time that I got bored of waiting, though I’m sure it was only a dozen or so seconds (I don’t know). But when I cut the second elevation, everything showed up instantaneously. Go Archicad!

Your .pln is full of garbage

Now that we have some basic understanding of what might affect file size, let’s apply this knowledge and some common theories to an existing file. I chose a project that was about 60 MB, which to me is a big file. If someone has a huge file they’d like to share, I’m all for doing a follow up post that looks at what’s happening in say a 200, 300, or 400 MB file.

My first test was to clear out the layout book. If you talk to BIM Managers at firms doing giant projects, a separate .PLN file for layouts is a must. On the 60 MB test file, getting rid of 54 layouts and 3 master layouts reduced the file to 80% of the original size. For HUGE files this is probably the number action you can take to reduce file size. It negates the benefit of BIMx Docs (since the Layout Book and model don’t live in the same file), but if you have hundreds of sheets bloating your file, this might be the only solution. But more importantly the lesson learned here is don’t unnecessarily duplicate your Layout Book. You don’t need SD Layouts, DD Layouts, CD Layouts, etc. When you’re done with SD, make a copy of the file for posterity, and turn the Layouts from SD to DD. And when you are done with DD, do the same…I could write an entire post on why you need to be doing that anyways, but file size alone is reason enough.

The next test was to clear everything from the embedded library: approximately 40 GDL objects plus countless abandoned jpg files embedded for use with materials, rendering backgrounds and png Objects. I left the stairs that were actually placed in the file.This dropped my overall file size to 44.1 MB, a reduction of 25%.

After this, I removed all linked libraries, except the Archicad standard library. This project had a Drop Box library with commonly used custom created GDL & GSM Objects, images, door panels and window sashes. This gave no additional reduction in file size. Well about 100k, but that’s about the same as just a bunch of 2D drafted information taken away from the floor plan.

Solid element operations used during the modeling and documentation of this project were the next thing to go. This only dropped the file size 1%. I then selected all walls (357 of them) and set them as a target, and all roofs (49 of them) as the operator. I subtracted with upward extrusion and took a 3 minute coffee break. Once the Mac’s rainbow wheel of death was done spinning the “save as” yielded a 6% increase in file size. That 6% was a game changer though—try this if you want to waste a lot of time with a slow, crash prone file. One more reminder that in all these discussions of slowness, crashing, and file size, not all bloat is created equal. A 6% increase in file size that breaks the usefulness of the file is much more extreme in comparison to the 1% saved by avoiding SEOs all together. There’s some sage advice here like “a tool used wisely remains swift. A tool used foolishly will get you fired.”

How about DWGs & PDFs placed on the sheets, plans etc.? I added a total of 7.0MB worth of pdf’s and dwg’s to the original file. The resulting PLN size was only 3.2 MB larger, so surprisingly not a one to one file size exchange.

I also went through and deleted the model and separately all the 2D information on the plans (Find and Select is a great feature for doing this sort of thing). You’ll notice that the file size didn’t reduce that much, UNTIL I subsequently updated all the views in the Layout Book (which I did via the Drawing Manager, but could have been done by just opening the Layouts and letting them automatically update).

Element Added or Subtracted From Template	File Size	Relative Size
None: original .pln file	58.1 MB	100%
Layout Book Removed (masters & all sheets)	46.7 MB	80%
Embedded Library Cleaned (40+ JPG & GDL Removed)	44.1 MB	75%
Embedded Library + All Linked Libraries (except Archicad Library 17)	44.0 MB	75%
All 3D elements Removed From File	56.6 MB	97%
All 3D elements Removed From File & updated Layout Book	39.1 MB	67%
All 2D elements Removed from Plans	57.3 MB	98%
All 2D elements Removed from Plans & updated Layout Book	56.6 MB	97%
All 2D and 3D elements duplicated 200′ over (double model)	61.6 MB	106%
All SEO Removed From File	57.7 MB	99%
All SEO Added (357 walls as target, 49 roofs as operator)	61.6 MB	106%
Added (10) 250k pdf & (10) 475k dwg to Project	61.3 MB	105%

Your .pln needs a diet

Layouts and the views they contain do significantly affect file size. Watch your embedded library use; excessive Objects can be a factor in file size bloat. For company standards use a project library and/or a general use “Drop Box” library. The external libraries seem to have little or no impact on file size, certainly less impact than Objects actually placed into the model. Solid Element Operations are not incredibly detrimental to file size, but really do task the software and hardware when improperly used. Lastly, you really need to be doing something crazy with your placed drawings to make DWGs and PDFs destroy your file size. Even a 30MB PDF (which for a single page PDF is HUGE) will only add about 12MB to your file size. So rather than worry about how many PDFs place, focus on how large the PDF file is to begin with.

What does this all mean? What Should I do now?

To me this post and the previous ones are about awareness. Other than Layouts, there is no magic bullet to decrease file size. And likewise with slow files, it is general diligence that matters. But hopefully after reading these posts you’ll look at your files in a different manner. And when MB start creeping up, or load times start increasing, you can revisit these posts to help you get some clues.With luck the mysteries of Archicad are now a little less mysterious.

Did this post inspire you to run some tests of your own? Or do you have some tests that should be run for a future post? Leave a comment. Have more advice on file bloat, slow files, and too frequent crashes? Leave a comment! Have an idea for what we should discuss next…guess what? Leave a comment!

Are you following GRAPHISOFT North America on Twitter? Click Here to keep track of all the latest Archicad News in North America (and beyond).