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.
