Schematic editor is very slow on large schematic

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).

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

3 Likes

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

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

11 Likes

v7 testing or v799 nightly?

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

1 Like

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

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

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

3 Likes

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.

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).

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

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).

I downloaded the nightly from yesterday evening. The performance-improvement is noticeable, could be very well factor 3. Still not as snappy as my own schematics, but workable (medium laptop with intel I5-1135G processor, integrated graphics).

I noticed another (different) issue with the hierarchy-panel on the side.
Selecting all 32 subsheet-rectangles on subsheet “Digits” (page4, top right side) and then move that selection causes the hierarchy-panel to scroll 3 times from top to bottom.
With so much subsheets (>300) this needs much time, stopping the workflow.
The difference in reaction-time can be seen if the hierarchy-panel is switched of intermediately.
@JeffYoung : will you look at this or should I open a gitlab-issue?

Open an issue please. I hate that dang wxWidgets tree ctrl, so I’ll avoid it as long as possible ;).

2 Likes

Never do today what can be put off 'till tomorrow. :slightly_smiling_face:

2 Likes

specially targettting the navigator-panel: hierarchy navigator performance with many subsheets (#15396) · Issues · KiCad / KiCad Source Code / kicad · GitLab

1 Like