Schematic Slow Performance

My schematic, now populated with many components, nets, and labels, is seriously struggling in performance to view and edit. Even simple actions like panning and zooming in/out are slow and unresponsive. I used EAGLE before and never noticed it being so sluggish. Is there something I should know about that affects the performance this way?

I never observed this myself, so just for interest: could you specify how many components you have in your schematics and are these on several sheets or just on one?

Also it would be interesting to know more details about your system. So far I have heard from this issue only from a Windows user with two high-dpi screens. Can you confirm that the 3D board viewer is not affected by this issue? For long term we might change the 2D viewers to the same technology as used for the 3D viewer which I expect to improve performance.

You could also try to enable OpenGL in the workspace settings, but so far I never saw a system where this actually improved performance…

Video demonstrating the effect:

You can see how the first sheet, with many components, struggles to zoom and pan, while the other sheets do not.

As for my system, it is a laptop computer with integrated graphics, nothing special. 3D viewer seems to work absolutely fine and smooth.

OK so generally I recommend to split schematics into smaller pieces anyway, ideally with a schematic frame to also make them printable in a nice and readable format. I agree for long-term the performance problem needs to be fixed but this is not trivial at all so it takes some time. On most systems this problem does not even exist, even with large schematics.

In my experience, performance problems are usually caused by rendering lots of texts (observed especially on Windows). So reducing the number of displayed texts should help a lot. In the board editor this can be done by hiding layers, in the schematic editor you could hide pin numbers (with the tool button next to the grid properties).

Also your symbols contain a lot of texts, I don’t understand why so many texts are needed :see_no_evil: Actually there should be no need to put manual text elements next to each pin. Maybe you should take a look at our official libraries how pins and pads are labeled :wink:

1 Like

Just to add another data point. I have just added 78 LEDs to a schematic sheet for a minor lighting project experiment. The schematic editor has become very sluggish, to the point of fully hanging for 10-15 seconds after trying to draw too many 1-grid connecting wires in a row.

I have an i7-13700, so definitely not a lack of compute resources. Possibly some big polynomial time operations in ERC?

@moshee When does it hang exactly? Only immediately after modifications (i.e. on mouse input events)? Or when zooming/panning? Or at random times?

And if you share your project, I could try to reproduce it on my computer.

Specifically it is slow when drawing wires. I am not at my computer now for a while but you should hopefully be able to reproduce by placing a ton of passives on a sheet at once and then try wiring them together.

i can confirm this (i’m on a mac with apple silicon).
Just checked with 100 diodes.

  • after drawing the first few connections in a row (“blind”, without waiting for the connection to be drawn on the screen) i see a lag of a few seconds (from mouse clicks to establish the connection until the drawing on the screen).
  • The more pins of the diodes are getting connected, the faster the operation
  • workaround: close all ERC docks (even the one of the pcb board if this is in the background).

Stephan

1 Like

That’s very interesting @sasmus! If your suggested workaround works, the bottleneck is clearly the UI of the ERC. That’s very valuable to know.

Maybe @moshee can confirm that this workaround helps?

1 Like

I closed the ERC window, and I don’t have layout open. It is a little better, maybe twice as fast, but still takes about 1 second to register a wire tool interaction.

I tried zooming way in and way out - no difference.

It does seem to be true that the fewer open connections there are, the faster it gets.