I’m sorry that my first post is basically Artax writing from the Swamp of Sadness: something I’m doing wrong is causing what seems like basic UI operations to slow down to an absolute crawl, and it’s getting worse, Fantasia style.
For context, I’m working on a 4 layer board with about 50-60 footprints. There are some copper fills, and I’m running a few plugins from the usual places. I do have a lot of user-created symbols, footprints and models, but everything will pass DRC, render in 3D and most importantly JLCPCB can produce viable boards.
I’m running v9 on a 24 core Threadripper 3960X with 64GB of ram and an RTX 2080 Ti, on Windows 11. TL;DR this should be blazing, but it is crawling.
Selecting a wire in PCB mode take 5-10 seconds, pressing U to select the whole connection takes another 10-15 seconds, and hitting delete takes another 20-30 seconds. It’s like 80286 AutoCAD speeds. Moving things around takes a minute. Refilling my copper zones takes 7-8 minutes. Even opening the properties window on an arbitrary object is taking 5-10 seconds.
You get the idea. It’s important to note that nothing else I do on this machine is particularly slow. I do a lot of Fusion and music production and I don’t see any slowness or jerking halts.
Here’s the thing: I just sort of assume that I’ve done something subtle and dumb. This is my first significant project in KiCAD, so statistically this is going to be something incredibly basic. Yet, at this moment I am stumped.
I’m happy to share my most recent project zip with an admin. Any additional information that would help I will do my best to provide.
An option in the net inspector panel config (click the spanner in the top right of the panel) is to show zero pad and unconnected nets. I suspect your missing nets are in these categories.
With minor caveats, it is all standard 90deg and 45deg tracks. When I started this project, in full noob glory I installed the curved wire plugin and went hog wild. I quickly realized that it was creating far more problems than it looked cool, and as of this moment I’m pretty sure that any arcs are purged. There might be 1-2 tiny segments hiding somewhere. I no longer have the curved line plugins installed.
Is there some way that a huge number of orphaned track segments are hiding somewhere? I don’t suppose there’s a track segment heat map?
A very small part of me wants to completely rebuild the entire project from scratch using as much standard default everything possible, but unless I’m fully confident that it’s necessary, this would be a large time sink and more than a bit risky as several items are in very strict locations in relation to the edge cuts.
As for the 8 minutes for a few copper fills, or the 4-5 minutes if I hit Undo… whatever I do, the UI freezes for n seconds or minutes of linear realtime, completely unresponsive. I have a high degree of confidence that it’s not a video perf issue, and I can and do tab to a different window to be more productive during this time.
It’s wild but I can actually compile, build and deploy in a different window faster than I can undo moving a footprint.
For what it’s worth, I am wildly impressed by the responsiveness and quality of the answers I’ve seen here. So many projects have forums full of super toxic people, so this is a real breath of fresh air.
Have you tried using the “Cleanup Tracks and Vias” tool ? don’t run it then save your project without knowing exactly what it has done . . . I never use this tool, Caveat Emptor . . . but if it helps it might give you a clue to what the issue is.
If that’s a subtle hint that my tracks and vias could use cleaning, I’m not offended! That said, I am wildly allergic to the idea of any algorithm attempting to clean my room while I’m at school.
I suppose I could back up the project and see what it does.
It’s really important (to me, at least) to restate that this is a working, manufactured board. So from the perspective of shipping (the mindset) I’m not feeling super keen about having everything redrawn. If you think it could disappear a few thousand mystery tracks, I’ll give it a shot. I’m just trying to wear my project manager hat.
By the way… is there a way to have two projects open at once, short of firing up a windowed VM? If I do have to rebuild this, I definitely do not want to have to jump back and forth. Give me your best multiple instance tricks.
This is a very simple PCB, and there should be no speed issues at all.
KiCad does have a bunch of multi threaded parts, but each have to be programmed separately, and many things are still single threaded, so the 23 of your cores are mostly twiddling their thumbs, or doing something else. Unfortunately this is still the case with many programs (In FreeCAD it’s a real annoyance, but that’s another topic).
The “Boatcontrol” project (I.e, both can be found on the Made with kicad | KiCad EDA page) is also a good project for performance measurement.
A simple & small PCB as yours should not be any problem. Did your problem occur suddenly, or did it gradually get worse? For example in the GitHub - Architeuthis-Flux/Jumperless: A jumperless breadboard project, KiCad has a lot of trouble with the graphic on that PCB, and it causes a very noticeable slowdown. Once the graphic is removed from that PCB, KiCad becomes quite responsive again.
Pretty much everything I can think of that is computationally expensive is multithreaded. If you’ve got any specific examples of stuff that is slow, we can take a look.
I’d say that it’s nudged from barely perceptible to a bit sluggish to problematic to holy crap what is happening over the year I’ve been intermittently working on it.
Unfortunately, it went from “I can wait until I get home” to “I need a bathroom right now” the moment I updated from 8.0.8 to 9.0 last night.
What a wild coincidence; I actually just/finally put my credit card down to buy one of his v5 jumperless boards literally yesterday.
With genuine irony, the other [separate KiCAD project] board in my project has heavy vector graphics and no performance issues at all.
On my Ryzen 5600G (6 cores, 12 threads) Fill all zones [b] takes about 12 seconds, and during that time processor load does not get above 30%. With one core, it would have been 8%, so it’s definitely multi threaded. I guess that using more then one thread for each zone (or layer) would make programming really difficult.
Not a complaint (people often interpret my comments in this way) 12 seconds for such an operation is noticable, but “acceptable”.
I haven’t used KiCad V9 yet, but it smells like you triggered some kind of bug in that new version. The first few iterations of a new mayor version of KiCad tend to be a bit buggy, and because the Python interface is also not standardized yet, many plugins have to be modified a bit to work with the new KiCad version.
One thing you can do is to progressively delete parts of your PCB in a copy. That way (delete about half each time) you can find out if one particular object causes all the slowdowns. You can also create an issue on gitlab, but you will have to upload the design. Issues on gitlab can be made confidential, and confidential issues can only be viewed by a very small number of people.
That is problematic indeed. What does “Boat Control” do in KiCad V9? For me (in V8) it renders in 13 seconds, as I already mentioned.
I just opened my schematic view for the first time since updating to v9, and the vast majority of my symbols have been X’d out. The ones that aren’t are ones that have been added to the board fairly recently. That said, I don’t think that there is anything special about them, beyond been new additions.
What does an X mean, exactly? Plague house, perhaps.
Those grey Xes are “exclude from simulation”. You can turn them off in preferences (schematic display preferences). Or otherwise remove the Exclude from Sim flag from the symbols, as it looks pretty randomly assigned in your schematic.
There’s an annoying limit with multiprocessing called Ahmdel’s Law, which is a formal expression of the maximum speedup possible in a parallel computation (they are bounded by synchronisation points where serial processing occurs). I suspect we’re hitting something like that here, but I haven’t looked at the zone filling code in detail: Amdahl's law - Wikipedia
