Slow performance with lots of XREFs

when working with 2D drawing which has lots of xrefs (it could be lots of copies of one xref) or even large xref, BricsCAD's viewport performance becomes very slow - both zooming and panning. Up to a state when it becomes unbearable. I tried to fiddle with XLOADCTL and SELECTIONPREVIEW variables with no positive result.
I know vieport performance is subjective - I am comparing the same file in AutoCAD (windows), DraftSight (linux) and BricsCAD (linux). In AutoCAD vieport is super-smooth. In DraftSight it's littlebit slow, but I am able to work with that file. In BricsCAD it becomes so slow, that I have to wait few seconds when zooming or panning. The differences are drastic and it seems from my research, that the problem in BricsCAD is that xrfes slow viewport performance too much. Especially compared to DraftSight. When working with large files, BricsCAD's viewport is much smoother than DraftSight's. But when I attach lots of xrefs (or large xrefs), BricsCAD's performance goes down, much more than DraftSight's. After certain amount of xrefs, BricsCAD viewport performance is slower than DraftSight's.
My system is core i7-3770 with NVIDIA 650Ti. Fedora 20 64bit with proprietary NVIDIA drivers. So it's not weak hardware problem.
I know I can freeze layers to avoid this, but that's workaround I don't want to use. Did anyone encounter this and found different workaround?
I am attaching my test file. It's a simple file with simple xref. The xref is copied 2000 times. This file becomes slow on my computer - not unbearably, but it's noticeable. I know 2000 copies sounds like a lot, but it's simple xref - that's why I had to use so many of them. When I work with my standard files, even few large xref files can slow down the viewport considerably.



  • yes, xref and some hatch will make bricscad slow down, we are all hope bricscad can be faster when working with big file large than 10MB. Compare to other CAD platform, we really hope bricscad can to better. I have check the multi-thread option, for recently bricscad it's still not work. 
  • Hi Sitian,
    in my experience, Bricsacad works with large files quite well (I don't work with files with huge amounts of hatches). The problem is, that xrefs slow it down quite considerably. Especialy compaerd to DraftSight in linux.
  • Hi Tom:
    Yes, I test on draftsight too, but draftsight feels more slower on large files and bricscad is more powerful so I abandon draftsight, but indeed the same file with xref is faster in draftsight. My system is a i7-3940 and nvidia card k2000m, ubuntu 12.04 64bit. The large file I mean over 10MB or 30Mb means contain lots of text, dimension, hatches, splnes works reailly painful on bricscad v12-v14. I have several windows system machine in office, bricscad windows will faster than on linux, but still can't compare to "ACAD" or ZWCAD, gstartcad. I send you three file to test, the screen hatch one is the most slowly one I feel. Really hope bricscad can be more faster.

    screen hatch.dwgansi hatch.dwgrec arrary.dwg

  • I tested those files.

    rec array.dwg - no problem in BricsCAD and DraftSight
    ansi hatch.dwg - no problem in btoh programs. DrafSight may be littlebit slower than with rec array
    sreen hatch.dwg - subtle slowdown in both prgrams when zooming and paning. It's wouldn't be a problem to work with them. DraftSight slows down more than BricsCAD in my opinion.

    I didn't test in Windows.

    I share your opinion that BricsCAD's viewport performance is better than DrafSight's. The only exception is when there are lot of xrefs in the file. And yes, Windows (I tested just AutoCAD and DraftSight) viewport preformance is much better than performance under linux.

  •  hi Tom,
    I can not fully reproduce your problem:
    your testfile feels a bit slow on my slightly outdated Macbook 6.1, but not to the extent that you describe. Also, binding/inserting or exploding the xrefs did not seem to have an effect on performance, but I confirm that the recent teigha viewer handles this file significantly faster than bricscad. So, my conclusion would be that bricscad misses some opportunities for optimization when it comes to a massive number of identical instances. Maybe you should file a SR because of this.
  • Hi Knut,
    I think it has to do with the graphics stack on linux. So it might be better on Mac or Windows.

    Thanks for the suggestion:
    1] I tried binding those  XREFs with no visible viewport speed improvement
    2] I tried exploding those  XREFs with no visible viewport speed improvement

    So it doesn't seem to be XREF problem as i thought.

    Makes me wonder which part of the drawing slows it down more rapidly in BricsCAD than in DraftSight. Because with some large drawings, BricsCAD is still faster.

    The other thing I observed is that when I am zoomed in on just part of the drawing, the viewport is not as slow as when I am zoomed out and can see all the entities of the drawing on the monitor. This is different, than how DraftSight's viewport behaves - it's speed is not dependent on zoom level or how many entities are on the monitor -it's speed is constant.

    I guess I'll have to investigate further.


  • Hello There,

    I am usiing the newest Version of Bricscad and have the same Problems as explained above.
    Do you need an example to reproduce that?


This discussion has been closed.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!