Schematic editor is very slow on large schematic

Schematic
1

I have been tinkering a bit with a project from another forum user, and I found that the Schematic editor is extremely slow on his large schematic.

I had not seen such performance problems before.
I also have not used KiCad V7 much.

Especially the repeat function with the [ins] key is very slow.

  1. draw a horizontal wire segment (and end it).
  2. Hold down the [Ins] key to repeat.

Now Kicad adds a new horizontal wire about ever 0.5 seconds (it used to be faster then the repeat rate of my keyboard, and so slow the keyboard buffer fills up with keystrokes (so it keeps repeating after you release the key).

Also with repeating labels with autonumbering it is maybe even slower. Also tasks as renaming local labels to hierarchical labels was very slow. That is:

  1. Go to the sheet with all the local labels.
  2. Select a column of labels.
  3. Right click and: change to / Hierarchical Label from the popup menu.

Then my Ryzen 5600G starts humming on a single thread (it has 12 of them) and you see the labels change one by one. Maybe this is also related to the “slow font rendering” issue I’ve heard complaints about. Also, with or without screen recording is no difference. Both are just as sluggish as pitch in an hourglass. See it for yourself:

If you want to try, the project is in this other thread:

My KiCad is getting rusty, to I thought to post it here (first) instead of complaining on gitlab.

1 Like
2

Posted a similar issue since experiencing performance issues starting from Kicad 7, but my PC has a old graphics card and designs are about 500~800 net). Was advised to disable cross probing in Eschema and PCBnew.

3

Thanks for the reply.
I did disable cross probing and tried again, with a column of 32 labels, which took 15s to change them all to hierarchical labels. So no change at all.

Edit:
In a second test, I exited KiCad after disabling cross probing, restarted it, and did the label change again, with the same result. So I very much doubt crossprobing is related to this.
This project also does not have a PCB yet (meh, it does have the file, but it’s 50 bytes).

4

The Change To issue is that we’re not batching undo for it. (And God forbid you do want to undo it, because you’re going to have to hit Ctrl-Z for each label.)

Some of the other issues may also be specific, or there might be a global performance issue…

5

I can also confirm the performance-slowdown on this specific schematic. I think it’s the big number nets. (edit)

1 Like
6

The “hold down insert key” is also the undo issue (though at least it’s correct there as it should be creating a separate issue for each repeat).

Note that these undo issues have been hugely improved for 8.0 (the general issue earlier, and the Change To issue just now).

7

Rats. Just profiled it. Maik is right: it’s the nets, not the undo issue. (Specifically, CONNECTION_SUBGRAPH::GetNameForDriver().)

3 Likes
8

I trust you guys take it from here.
I could report it on gitlab if you like but that’s the limit of my own Voodoo Ninja Skills.

1 Like
9

I fixed the existing cache and added a second level. Operations in this document are now about 3X faster.

11 Likes
10

v7 testing or v799 nightly?

11

Nightly. Testing is frozen except for critical regressions until we release 7.0.7.

1 Like
12

17 posts were merged into an existing topic: Import boards from altium

19

4 posts were merged into an existing topic: Import boards from altium

31
32
33

Cleaned up this topic by moving the hijacking posts back to the correct topic.

3 Likes
34

Well, the original issue is pending a commit, which is queued for after 7.0.7 release.
As I understand it, each label change caused a netlist cache flush.

35

The current nightly was not updated the last 2 days, so I could not test the proposed fix. If I get a updated nightly version (and then get test-results) I will write a note.

As I understand it, each label change caused a netlist cache flush

It doesn’t only affect the labels. Each operation (even creating simple descriptive text) takes more time than on my usual schematics. (which are also not small).

36

That might well be the “Undo” issue. File operations on Windows crawl.

37

Note also that only the top-level cache is flushed (the pre-existing one, which is now only used for labels with text variables in them). The lower-level cache (which was added a couple of days ago) is managed on a label-by-label basis (so other labels aren’t flushed when one is changed).