Posted by dxli on Oct 27, 2024; 3:34pm
URL: https://forum.librecad.org/librecad-slows-down-tp5725511p5725516.html

@sand1024

At the algorithm level, we still have some expensive complexities:

For example, intersection finding, we are doing it O(N^2), trying to find intersections pairwise.

For block(text), we need to review updates sequences. I won't be surprised if there are quadratic or even exponential algorithms. For example, we may call a parent updating and trigger recursively updating all direct children.

For intersections, using r-tree might avoid the quadratic in some cases: like lots of small bounding boxes.

For blocks and texts, we just need to rewrite some algorithms to provide DFS type of updating sequence to guarantee linear complexity.

sand1024 wrote

hm... well, that's file from test set is quite a heavyweight considering amount of entities...
And on "zoom to fit" zoom level - indeed, potentially snap may slowdown (simply because there are too many entities around snap positions).

So another question there - do you experience performance drop on each zoom levels or on some specific ones?  Say, grid status value may be helpful.

Also, could you please also try to disable all snap modes, and find the minimal combination of enabled snaps that leads to performance slowdown?

For example, "snap to grid" itself works just find, "snap to entity" - suppose it is slower etc.

Also, could you please create a ticket on GitHub with details? (https://github.com/LibreCAD/LibreCAD/issues)
Thank you.