Bricscad BIM laggy when closing files ? (Giving RAM back)

Michael Mayer

I am talking about Windows Version of Bricscad on Windows 10 20H2.
(Ryzen 3950X, NVme SSD, 64 GB DDR4, RX6800 16 GB)

I access and save my Files from a "Server" Drive in LAN.
1 GBit LAN, external Thunderbold enclosure, standard SATA 1 TB SSD
on a M1 Mac Mini.

OK, saving large Files from Bricscad is pretty slow,
but that could be Firewall/Network/Mac vs PC issues.
(No noticeable Problems from Vectorworks or other Apps though)

And for reasonable DWG File Sizes like up to 10-30 MB it QLSAVE seems quite ok.
t starts to get a bit annoying for 50+ MB DWG files sizes.
But I often have DWG sizes from crappy IFC/Revit Imports up to 980 MB.
Saving will take 5-10+ Minutes.
OK.
(No noticeable Problems from Vectorworks or other Apps though)

But what I really don't get ...
When I have Files from 50 MB - 1 TB DWG file size, and Bricscad may need up to 20 GB of RAM ...
When I save such File and wait my 10 minutes to save ...
don't do any changes ....
and just want to close that file from File Tabs ....

It will take at least another 10 Minutes until Bricscad finally just closes the File and frees RAM.

You can Watch Windows Task Manager how Bricscad will cozily free about 200 MB of RAM every second or so.
(No noticeable Problems from Vectorworks with similar (also compressed) File Sizes or other Apps though)

It looks like there is a certain File Size Limit where Bricscad will save and close Files in realtime,
but at something above 30 MB DWG size, it will start to take more time exponentially (?)

Has anybody else noted such behavior,
or is it again just my configuration or potentially AMD GPU ?

Torsten Moses

Hi, Michael,

maybe it is related ... when using MultiThreading (MTFLAGS > 0), and you have lots of ACIS objects, then releasing that emory consumed by ACIS (in multiple threads) is rather slow, around 3x slower than without using MultiThreading;
that seems to be an internal ACIS problem, how it releases MT-allocated memory ...
so at Bricsys side we can't do really much here (except to ask Dassault/Spatial about).

You might try with MTFLAGS=0, to see if releasing the memory (using same dwg) is faster with MTFLAGS=0 vs. MTFLAGS = 7.

hope this can explain a bit ?
many greetings !

Michael Mayer

Hi Torsten,

sounds reasonable.
I will try without MT again.

Forgot to tell the workaround :
Instead of closing the file,
you can Exit Bricscad.
Bricscad will disappear from screen but the BC Thread goes on running
until it has worked its RAM game.

But at that time you can open Bricscad again which will use a new Thread
so you can go on with your work and load new files.

A bit tedious but definitely faster.

Michael Mayer

I tried without MT.

But for my kind of crappy large files provided, that is no alternative.
Now I have to wait for opening files instead, even more laggy viewport,
saving files and everything else multiple times longer.
Couldn't event check if closing a file is faster, as I could not wait until the
file saved and went away instead.

For me, for a reasonable DWG size and quality, Bricscad is great and I
appreciate very much any of its future proof approaches in many directions,
but in my reality I still need Vectorworks to do the jobs done reliable.

Torsten Moses

Hi, Michael,

yes, MTFLAGS=0 might not be an option them I completely understand ... it was just ment as a "proof of theory", about the ACIS' slow memory release under multithreading :-)
many greetings !

Michael Mayer

Hi Thorsten,

I tested again without MT with my 420 MB DWG.
(I learned that DWGs above 100 MB are monster files ?)
Now from my local NVme SSD, to exclude any LAN bottlenecks.

It loads single threaded, with about 30 MB RAM junks per second and will
take many minutes.
(About 17 MB RAM in total ?)
(6-10 minutes load time ?).
Panned in model view.
CMD+S qsave.
(similar time, maybe half of opening time)
Close file by clicking X on File Tab.

But it still frees RAM slow with about 30-300 MB junks per second !?

So maybe not the special ACIS MT Threads bottleneck ?

BTW,
the file is basically the IFC import from the FIRE.ifc.zip I attached in SR 125720

Torsten Moses

Dear Michael,

So maybe not the special ACIS MT Threads bottleneck ?

hmmm, I tested this problem a while ago, under Windows, and that problem was even confirmed by our other developers ... so that ACIS MT memory release performance issue is clearly present.

But as you describe, the memory seems released very slowly, and I see, you are on a MAC ?
Sounds a bit as when releasing memory on MAC is generally slow ? (do you have similar effects with other programs, VW ?)

Best not to close the drawing only, but enitre BricsCAD ... (as there might be pending memory references, which are released bby a) opening another dwg file and/or by closing BricsCAD itself.

many greetings !

Michael Mayer

you are on a MAC ?

Dear Torsten,
no, that was all on the PC.

I already tried the file from local SSD and there was no difference vs network volume.
And all other Apps, especially Vectorworks, with the same imports, saves and closes
at reasonable times on the network drive.

There is nothing special about the PC and I see no problems with Modo, Cinema,
Blender, VW, ... either.
AM4 board with latest BIOS.AMD Ryzen 3950.
OK, not the fastest RAM, DDR4 2400, 64GB
The only thing that is a bit strange is the AMD RX6800 16 GB VRAM replacement.
Not that I see problems with other Apps, beside Bricscad crashing with latest driver,
but I think the drivers aren't that good and it felt like the RTX 2070 before was
faster (?) or more fluid and reliable.

Tested on M1 Mac Mini too.
Could not open that 430 MB file but tried a similar file with 220 MB.
Takes long to load with all MT ON and closing the file, after being saved,
looked similar slow for a moment (about 30-100 MB RAM per second).
But only for the first 500 MB or so, than it closed the file and freed all
RAM at once.