How to keep files running fast and lean.

How to keep files running fast and lean.

Even the smallest of projects can get bogged down, decreasing the speed of everything from selecting an element to generating the 3D window. While ArchiCAD becoming sluggish is bad in itself, this slowness often raises the potential for file crashes. Even if a project doesn’t slow down, an ill-maintained and operated project can also cause more crashes than you should have to deal with.

Increased crashes and slow files should not be a common occurrence.

These problems can and should be avoided. Educating BIM users is the first step; there are some critical things to do or avoid to prevent problems. There is also a range of possible fixes, some quick, others almost as annoying as the slow running file was from the start. The list below is not exhaustive, but it contains some common issues I have come across in my time as an ArchiCAD user, BIM Manager, and someone who loves talking shop with every ArchiCAD user I can find. In fact this whole article came out of some discussions I’ve had with another BIM Manager and power user: Patrick May. You might remember Patrick from these two posts from 2013.

Common causes for slow running ArchiCAD files

  • Missing and Duplicate libraries (this comes up a lot and gets ignored a lot)
  • Poor library management (how thick does the embedded library need to be?)
  • Excessive use of solid element operators
  • Out of control Element Attributes
  • Poor window management

Techniques for Speeding up Sluggish Files

First, check the library manager for missing or duplicate library parts. Duplicate library parts are very common if you have a firm standard external library, and then embed some of these parts or name a new part with the same name in the embedded library. If you click on the library part name in the Library Manager window you will see the number of instances this object is used at the bottom of the manager window. Doing this makes it easy to weed out the duplicates between embedded objects and linked library objects.

Getting rid of missing Objects is a little more tricky, and involves going through the entire project searching for missing objects. Normally I search every story, elevation, section and detail window for the large dot (the dot color depends on a pen number assigned to the missing element) that signifies a missing Object. You can then either delete or re-link these Objects to non-missing parts until the Library Manager comes out clean. If you want more information about missing Objects, check out this post that talks about the value of the .PLA).

LIb_manager_1 MisOb_1Associated with this first step is cleaning up the embedded library. Multiple stairs, door panels and window sashes are often created during a design process. Most of these are abandoned but never eliminated from the embedded library. Take a moment every so often and delete those unused Objects (since you have a good backup strategy you can always find them in an old version of the file if you decide you need them later). Likewise linked libraries can get huge, bloating file size (more to come on that), and result in chronic slowness. An external library linked in via DropBox is a great way to store commonly used gdl, gsm, jpg and png files, but if everyone is adding to that shared folder in a non-structured manner, things can get ugly fast. Keep an eye on those linked libraries and periodically clean them up too.

More often than not, simply cleaning up the Library Manager is enough to speed up the project and eliminate frequent crashes.

Placed stair 1Unplaced stair

If cleaning up the libraries doesn’t fix the problem the next thing to look for is excessive use of Solid Element Operations. I recently came across a file that had an SEO operation with all walls as the target and all roofs as the operator. This is an extreme case, but it certainly was enough to kill the file speed and cause regular file crashes. The best way to prevent this is to be sure that all targets are related only to the operators they will trim to when performing the operation. The fix to excessive SEO usage is to select all and cancel all operations in the SEO dialog box. One more thing about Solid Element Operations. They are a great function of ArchiCAD, but it should never be the go-to solution. Before you jump to using SEO, think about creating the same forms with different tools. I’ve found that much of what I used SEO for in ArchiCAD 16 can be handled with smart use of Building Materials and Priority Based Junctions in ArchiCAD 17. Likewise creative use of Complex Profiles can also obviate the need for an over abundance of Solid Element Operations.

SEO_1 SEO_2 SEO_3
If the slow file is not fixed at this point, look in Element Attributes. The Attribute Manager is a great tool to solve this problem. If you open the Attribute Manager and select the “ALL” tab you will see all Attributes for the project in a single list. If you select “Purge Unused” it will drastically clean things up quickly. Scroll through the list looking for any duplicates, usually identifiable by a (1) or (2) at the end of the Attribute name. If it is a composite for example, you can then open the composite structure dialogue box and delete the identically named profile and replace it with a unique profile. This is a recent improvement to ArchiCAD’s attribute management. Note: the delete and replace option is not available from the Attribute Manager. For more on this topic, check out this post on Missing Elements. One more thing about this solution: be careful. It’s easy to go overboard and delete more than you need it. This fix benefits from trial and error. Clean up the Attributes and see if the file functions better. If it does, load a pre-cleaned file and delete Attributes more carefully until you fix the problem.

This option is often a scary one for BIM users, but using the Attribute Manager to its full potential means being able to bring Attributes from one file to another. If you remove an unused Attribute to speed operation up, then realize that you are missing a wall type, pen set, etc. you simply need to bring it back in to the attributes from your template (or an earlier version of the file). For more details on how to bring in Attributes from another file, read this post.

Attribute managerAttributes_2

The list of reasons your experiencing sluggishness is long and varied. And I hope we can discuss some more problem areas and solutions in the comments. In our discussions Patrick and I came up with many others, but I’ll include just two more.

If you find your file is being sluggish, make sure Virtual Trace isn’t defaulted to “on”. As a project gets bigger, leaving that on at all times can often be a source of slowness. Finally, limit the number of windows open. If you have a dozen building elevations, 3D documents and sections open, I’ve seen this slow things down. Background processing helps alleviate this, but if you have a bunch of windows open perhaps the biggest danger is accidentally clicking on another window and getting slowed down by regeneration—especially if that window you clicked on is say a Layout with a few dozen detail views set to automatic update. Along with this, I always recommend saving a .PLN file with only the plan open, it just keeps things efficient and makes things easy on the next person in line to open the file, not to mention it will cut the time to open a file nearly in half.

And of course if you see slowness, don’t forget the #1 best IT problem solving solution. It is unreal how often that one simple solution will fix your problems.I hate when this happens

Crashes will happen. Crashes are inevitable. Hopefully the above techniques will help. If you have a file that gets slow and crashes often, try these techniques. If they don’t solve the problem, ask for help. Call Tech Support, ask on the forum. Don’t accept crashes and slowness. No program is perfect, but don’t assume these problems are unfixable.

And finally, if you do get a crash send that crash report to Graphisoft. If you keep hitting a bug, it’ll never get fixed if only you know about it.

 

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

11 Comments

  1. My policy is that you should never see the library loading report. If you see it and don’t fix the issues, then 1) You have issues, and you likely don’t know their true impact, and 2) You get habituated to dismissing the warning, so that if it ever needs to warn you of something serious, you will have no idea because you just click it away by habit. Same with the Report window popping up. Quit ignoring it, fix the problem. Maybe the Report is telling you about an error in an object that’s been fixed, only you don’t know because you don’t know which duplicate you’re using.

    That said, I’d like to know more technical detail about the impact of lots of duplicates on file performance. Is it just at library loading and in the settings dialogs, or are there other effects?

    In regard to proliferation of windows. Work Environment : User Prefs : More Options : “Prefer to open in existing window” when opening a view, viewpoint, or layout. You can always open multiple windows case by case with the context menu.

    Maybe it has changed, but they used to say that having many many sections and elevations could hurt performance, independent of actually having a lot of them open in windows. For this reason, I have long tried to limit the number of “junk” sections used as modeling aids (not for output). I prefer to have a few of them and move them around, rather than constantly add new ones.

    You didn’t mention Trimming Bodies in the discussion of SEOs? Is there any difference for performance?

    Is RAM the bottleneck for some of these things? I believe in running a very clean project, but eleventy-seven gigs of RAM seems like it could cover for a lot of slop.

    Lastly, I shut down the machine every day, and AC and the system as a whole seem happier for it. Preemptive IT solution #1.

    Reply
    • James,
      some very good points… I completely agree, most users do seem to ignore loading reports because it is not exactly clear what the solution is.
      I think it is great to strive for a clean model with few section markers, but it can be a lofty goal with multiple users working through preliminary design process. I routinely “clean up” process section markers and shut down unused windows. I have a layer for locking section markers with critical 2d information that I need to keep during the design process.
      I’m not sure that increasing RAM, although it seems like it may solve some problems, is a good solution. In my office it would only encourage ignoring the warning signs; I have an error message but the file still runs fast, so I’ll just keep closing it.

      Reply
  2. James, awesome points as always. I completely agree with never dismissing error messages. I should have put that in big bold letters at the start of the article. I’m so used to never ignoring them that it seems obvious, but yes it needs to be said.

    I’m not sure about Trimming Bodies vs SEO. That might warrant a follow up post. It seemed like historically trim to roof was better than SEO for performance, but I don’t really know. Seems like some bench marking tests could be done.

    Also the RAM question is another great one. I have been using 16 GB for two years now and whenever I have a machine that can do 32 GB or more, I’ll do that the moment it’s economically feasible. I have another post started that touches on this, but I’m always modeling til the machine slows down (okay that’s an over simplification, but as power increases so does the easy of doing things); so in a sense this is all relative, right? If you have a more powerful machine you’ll hit RAM and CPU related issues, just later. But since you have a powerful machine you should be pushing til you hit the limit anyways…okay so that’s a half formed thought.

    I’ll hopefully finish up the ‘what causes file bloat’ post later this week and get it shared next week. When Patrick and I were talking about this article, that one was an obvious extension so we ended up talking about both topics. And we ran some cool tests that looked at the effects of tons of SEOs, objects, 2D elements, etc.

    I don’t think I shut down my machine enough. That’s another great point. Thanks!

    Reply
  3. I think the issue of trimming to roof vs. SEO is a matter of what you are trying to achieve. I remember using the trim to roof to get a wall to follow the slope of a stair, beam or other object. it works great until the angle or orientation changes. The SEO is awesome for associative objects, and really is only a problem when, as you said, an extreme case of misusing the SEO. Really v.17 has eliminated a lot of the SEO’s I use.

    Reply
  4. Good points here again.

    Another consideration is duplicate elements. I’ve seen this bog down many a new user’s project. Running the Check Duplicates add-on resolves it rather quickly. Same thing for polygon count which tends to slow projects down even more severely. Running the PolyCount add-on to reduce the polygons can have huge speed benefits, especially when frequently accessing 3D or S/E windows.

    Removing duplicate library parts speeds up the loading of a project (more so than fixing the missing parts IME), and while I don’t know the technical details, it is a major issue with Teamworked projects, as ArchiCAD will download each library on every client and sync the changes with them all for the life of the project. I personally always show users how to embed them all, while still following the Embedded Library/ Office Library / ArchiCAD Library methodology. Depending on user requirements and the complexity of the libraries, I have sometimes kept folder structures in the embedded library and sometimes reduced them to one single folder, but was unaware of any performance differences between the two options. I’d be interested to know if there are any notable implications.

    I also like never to see the Library Loading Report. Don’t forget that you can use Find & Select to find any ‘Missing’ library parts, but as we all know this exercise is often akin to a wild goose chase, as you need to go to about every viewpoint separately with all layers showing until you find the culprit(s).

    People don’t often realize the overheads involved in keeping virtual trace turned on. Since separate trace references can be on for about all the viewpoints (including layouts), it’s a great idea to teach people to get into the habit of turning it on, using it, then turning it off, whenever possible.

    Even just in creating templates, I religiously close all background windows, and your work environment profile can include a keyboard shortcut to the ‘Close All Background Windows’ command. It would be good to see continued improvements in background processing to hopefully eliminate any and all performance issues.

    This is an interesting topic, hopefully we’ll hear from GS about any of the above as well as the impact of other settings, like Floor Plan Cut Plane use, auto-update drawings and S/E and other viewpoints, Connect(ions), embedded drawings, etc.

    Cheers,
    Link.

    Reply
  5. The “Purge Unused” in the Attribute Manager, I think shouldn’t be taken so lightly. Some GDL scripts may use attributes that are considered as unused and if you delete for example unused Building Materials they may be used by unplaced Composites. Which I guess brings us back to having well a organised set of Attributes – a nod to Nathan on that and some of your previous posts.

    Reply
  6. James, very true. I think that’s a good view of all trouble shooting tips. Always do a Save As first and don’t do anything lightly!

    Reply
  7. Two comments:

    1. Attribute management – note on article – take extreme care removing attrributes with files that are hotlinked into other files. Ending up with attributes out of step is a major issue and can cause more headaches than the problem you were trying to fix.

    2. Session report – additional important thing to watch out for – if a session report launches when you are going in particular to your 3D window don’t just close the dialogue and carry on. It’s opened for a reason so investigate first. Most of the time it jumps open is because there is an issue with an object(s) in your file. Find and fix the issues immediately before carrying on! Many people ignore this and wonder why their file constantly crashes. Warnings happen for a reason.

    Reply
  8. Excellent article, and great discussion on an important topic.

    In addition to the points mentioned, I’d like to add the following:

    1) Excessive detail in meshes can bloat the polygon count and make the 3D window very sluggish. This can easily happen when users do a magic wand for site contours based on an imported DWG survey. I always recommend manually tracing the survey and judiciously picking the level of detail for tracing the contours based on how much they will be seen – areas near the building need more detail since they may be seen in sections and affect grading, while outlying site areas will only be seen for context so don’t waste time or polygons tracing them with too many points.

    2) Certain elements can create a ton of polygons, particularly if they are representing natural forms such as trees, or have a lot of curved surfaces (door knobs, sink taps, balusters, railings and toilets come to mind). These may be ArchiCAD library parts, or generated parts from modeling operations and tools such as Complex Profiles, TrussMaker, Shells and Morphs, etc.

    Imported components from manufacturers (brought in from DWG, IFC, SKP or 3DS formats) may be modeled in exquisite detail, far too much for practical use when placed dozens or hundreds of times in a large model. The use of the PolyCount add-on can be essential in diagnosing where the issue is coming from, and to focus efforts on simplifying some model elements.

    3) 2D slow-downs may be caused by imported DWG files (XRefs or Objects) that have tons of lines and fills. Sometimes I have turned off layers to see what is causing delays in panning, zooming or redraws; other times it is obvious as a certain element seems to take a long time to draw.

    4) Objects that have a script to show a top-down view that dynamically updates can also cause slow-downs. This is a powerful option, so I routinely use it for certain GDL scripts, but can be an issue in rare cases.

    I’ll probably think of a few more things, but this is good for now…
    Looking forward to reading more comments and ideas from others!

    Eric Bobrow

    Reply
  9. Nice article, and discussion! I would like to add, or reinforce a few things.
    If you need to xref .dwg’s from consultants, try to only load the ones that you need, and don’t leave them in the file. I prefer to x-ref to worksheets, (or even better, use drawing tool to import to a worksheet) and use this worksheet as a trace. And when I do not need them, I unload or delete them.

    Also, remember that in AC17 you can delete layers, and put elements from those layers to another layer.

    Handling large .ifc files. I prefer to open those separately (not merge), save them, and Hotlink it into my project. That way I can first see that they work in ArchiCAD, and also change some materials if it will be shown in a visualisation.

    In teamwork projects, one person should be responsible for handling external references, as undisciplined use of untested x-ref’s and hotlinked references can quickly kill a project.

    Reply
  10. Really useful article. Nice and clear. Thanks guys

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>