Hi,
I am able to achieve my goals, but with VERY significant slow down being the norm. I understand that I am using KiCad in a way that it was not really intended, but I have to import geometry to really build what I’m building accurately.
Basically, I have to import DXF/SVG geometry in order to produce the intended boards, and even when optimizing the number of objects in the system, I get MASSIVE slowdown (Program will completely freeze 5-10 minutes at a time) any time I try to modify any of the fill zones. Even just opening the project takes upwards of 10 minutes sometimes, and this is with the simplified project I will attach. I have tried all of the suggestions I’ve found here already with no luck.
During lock-up/freezing behavior, CPU utilization sits around 10% max (I assume because there is no multi-threading happening on my 12 core). The program just says it is not responding during this behavior, but usually eventually chugs through it and completes the task. Anyway, here is a simple version and a complete/production ready version of my project. The simple version has been updated so that the geometry actually imports as circles, eliminating a LARGE number of objects (20k~ down to 6k~) in the project - I hoped this would make a significant difference in performance but no luck. Please let me know if you have any suggestions to at least improve my situation. Thanks!
-True
I raised this issue a few months ago, it is not related to your processor, it is a problem with the PCB editor, it cannot work with graphics in multi-threaded mode, that was the developers’ response.
Ok, does that imply that they have no plans/interest in improving performance for this specific use case? (the developer response that it cannot work with graphics in multi-thread)
I understand if that’s the case, just trying to explore all avenues before accepting my fate.
I actually just did a small test without importing geometry, adding circles with the built in tool - with a similar number of objects (6000~) - the same issue persists. It seems obvious that it is just not optimized for so much geometry… Anyway, just making sure I’m not missing something obvious. Thanks!
-True
everything is correct. the problem is not in the amount of graphics but in the lack of load distribution across all cores. no matter what processor you install, the load only occurs on one core. I don’t know about the optimization plans, but there are quite a lot of open performance issues on gitlab.
You need to copy all the version information from the about box and put it into the provided space (or just use the Help->Report Bug menu item). That contains things like your OS and graphics drivers which can be very important for performance issues.
Thanks for the info. I used the Report Bug option and I might have gotten it formatted well enough that the bot didn’t immediately close my post. Thanks!
-True
Yeah that’s correct now. If you forget in future (we’ve all been there), you can also just add the version info into the old issue and reopen.
It’s annoying, but not as annoying as hundreds of issues that we can’t do anything with because we don’t know if it’s a platform thing, a version thing, a Wayland thing, or what.
In this case, it looks, at least partly, like a sneaky quadratic algorithm that’s blown up by the thousands of segments (i.e. the aforementioned CPU threading won’t help a huge amount here).
This is not true. The problem with this design is triggered by the use of board outline shapes instead of NPTHs to define a large number of circular cutouts. This can be improved within KiCad code (but also by using NPTHs to define board cutouts that are circular) and does not have to do with using multiple CPU cores.
More cores don’t save you from quadratic algorithms for long. That’s wasn’t the issue here and even 100 cores would still be slow on this board.
It’s not to say that there aren’t places where multithreading could help in KiCad, but in this case it would be like thinking using a paintbrush in each hand to paint the Forth Bridge would get it done by the end of the day.
Do you really think that introducing optimization into graphics will replace the lack of multithreading? I understand that it is much more difficult to organize multithreading than to make changes to the code to optimize graphics. But the global problem is not in graphics but in threads on complex projects. In practice, optimization will give a result instead of 15 minutes, say 8, and then everything will rest on one thread.
18MB for the PCB size is quite big. (I don’t have a dropbox account, have not seen the PCB).
“Boatcontrol” is probably the biggest PCB I’ve seen (8.7MB file size) and a “refil zone [b]” takes around 13s on my Ryzen 5600G (Project on github and on KiCad’s website)
“Jumperless breadboard” has a a few graphics on silkscreen (shown below) that causes a noticeable slowdown in KiCad. I was thinking about creating an issue for that on gitlab when I first saw that project, but never got around to it.
Edit:
The slowdown (in KiCad V8) seems to be much less then what I remember from a few years ago. It’s also not only the “apartment building”, but also the “Woman” and the Kevin Santo Cappuccio text. Filesize is 38MB. Rendering now is less then a second, and that seems quite acceptable. (I think it was 15 to 20 seconds back then)
In this case, yes, absolutely. Algorithmic improvements could be thousands of times of speedup here for large polygons, multithreading at very best would be about 10x. Take the current fix for a test drive and see how it goes and report back with numbers.
You are derailing this thread with your pet peeve about an utterly different issue, and the issue you linked has had substantial work done already and there will be more to come.
These are not my nitpicks, forgive me, the performance problems have been hanging around since at least version 7, they are several years old. For example, the zoom problem has been patched for more than three months, but it has not been solved globally, it has undoubtedly become faster, but the lags on complex projects are still there.
