fritzing gets slow with complex circuits

[davidperrenoud]

From irasc...@gmail.com on July 06, 2010 05:37:25

see attached

Attachment: DEP111.fz

Original issue: http://code.google.com/p/fritzing/issues/detail?id=1171

[davidperrenoud]

From irasc...@gmail.com on July 06, 2010 04:02:45

Gijs suggests making the ratsnest wires optional, and that's worth considering.

[davidperrenoud]

From irasc...@gmail.com on July 24, 2010 14:20:09

We've had one or two more examples of this. At around 50 parts in a sketch, Fritzing starts to crawl. At least part of the problem is all the generated ratsnests. But another issue is that after every change the routing status is recalculated from scratch. It may be that we have to keep a status data structure around and modify it, or it may be that the update has to be requested manually.

Labels: -Priority-Medium Priority-High

[davidperrenoud]

From irasc...@gmail.com on September 20, 2010 14:37:38

Still plenty of optimizing work to do here, but ratsnests are now order N instead of order N-squared; and a number of unnecessary calls to routing status have been eliminated.

Status: Started

[davidperrenoud]

From irasc...@gmail.com on September 27, 2010 14:03:11

Labels: Component-App

[davidperrenoud]

From irasc...@gmail.com on November 20, 2010 20:56:14

Issue 1218 has been merged into this issue.

[davidperrenoud]

From irasc...@gmail.com on January 29, 2012 01:52:02

always room for optimizing, but no one's been complaining lately

Labels: -Priority-High Priority-Medium

[e7p]

Fritzing still gets pretty slow on projects with hundreds of components. So I would consider this issue still as relevant. The idea for a setting to disable ratsnest would be pretty good as that would definitely increase productivity while designing.

[gieskes]

indeed its super slow on large projects

The idea for a setting to disable ratsnest would be pretty good as that would definitely increase productivity while designing.

please do this if it works..

i bought a new computer in the hopes it would increase the speed, but it still leggy allot, activity monitor shows +100% if i do anything. like move a resistor a bit in pcb view.

[xotmatrix]

The sluggishness of Fritzing is killing me. Yesterday I worked on a 14 component computer module using three 830 boards and around 100 wires. I estimate I spent a total of three hours waiting for Fritzing to recalculate its networks after every tiny change. That is not counting lost time due to errors caused by trying to work too quickly. At this point in the project every connection change takes 8 seconds to resolve. A way to disable or delay the updates would be a major QoL change. Updates done in a separate thread would also be a big help. I've got 8 CPU cores and only one is being utilized.

[haimiko]

I'm seeing this issue as well. Any updates on this? I can no longer edit my file. I left it running, thinking it just needed to do it's thing and it consumed all 16GB of ram through memory compression on Windows 10.

It looks like it's stuck in a file creation loop. See picture below

Exhibits the same behavior on Ubuntu 16.04.

One note. I am able to fix the slowness, if I switch back to breadboard view, then back to PCB and quickly select View-->Fit in Window. Then zoom in. Afterwords I can work as normal

Eureka! Removed show grid in the view menu and slowness completely resolved!!!!!

[failiz]

Please, upload some files, so we are able to test the performance and study the bottlenecks.

[xotmatrix]

I stopped using Fritzing 3 years ago (version 0.9.3) but this is what I was working on when I posted. registers-and-alu-3.zip

[failiz]

Thanks for the file @xotmatrix (and cool project). I tried it, and I could not experience any appreciable sluggishness when moving/adding components or wires. My computer is quite new and this was three years ago. However, I experienced a big delay when pasting all the components again (around 30 seconds) and a few minutes when I copy/paste again (four circuits in total). Then, zooming is extremely slow and adding a wire has a lag around one second.

[KjellMorgenstern]

Maybe related to #3084 . That one is quite easy to reproduce. Just choosing a big stripboard might do it (there is already a warning dialog that will tell you performance will degrade)

[xotmatrix]

When I tried my file with the same installation of Fritzing on the same computer I had been using in 2017, it wasn't as sluggish as had been, at least on immediate use. Delays between operations were closer to one second rather than eight. Perhaps after some more use it gets worse. The description of my experience in 2017 was not exaggerated in any way.

[failiz]

Remove imported label. Add performance

[KjellMorgenstern]

The effect described by @failiz is not related to #3084 , but to the way Fritzings Undo / Redo storage works.

[AndrewMatthewman]

Copy of my post on the Fritzing Forum wishlist category. I developed my first project on a 78x39 stripboard, and it was slow ! And yes, there’s a message to warn you. I worked in the breadboard view, placing the parts before breaking and linking the strips. What I noticed was that as the project was routed, performance went up and became quite acceptable at the end. I conclude that Fritzing was trying to make sense of my placement-only design and that this was computationally intensive. Here’s my suggestion : have a routing/initial wiring mode which disables the calculation and allows you to rough out the design before asking Fritzing to interpret what you’re doing. I’m glad I stuck with Fritzing through the period of poor performance because the end result is very successful and it’s a tool well-adapted to the job of designing for stripboard. Thanks.

[failiz]

The effect that you notice is related to the amount of connectors connected to other connectors. When you start stripboard, you have long stips and when you add a part, a lot of the parts connectors are connected to other connectors. This triggers a combinatorial explosion that the Fritzing algorithm cannot handle in time. We should optimize that algorithm.

The work around is to cut some of the strips before adding the parts, then add the parts and cut more strips and finally, re-join the strips that you cut at the beginning that you need in your design.

That effect was causing the application to freeze before as the stripboard was shorting vertical and horizontal connectors after resizing its size, see : https://github.com/fritzing/fritzing-app/issues/3084 https://github.com/fritzing/fritzing-app/issues/3090 We fixed the shorting of the connectors and that improved the behavior, but the algorithm still needs to be optimized.

[KjellMorgenstern]

Fritzing 1.0.4 on Ubuntu 22.04 With a 78x39 stripboad 2560x1600 window sketch scaled to the window ( Press Ctrl-0 ) I get around 16fps when moving the mouse cursor over the board (way to slow already). It doesn't seem to be affected by the layout , No Strips and Horizontal Strips doesn't show a difference.

This might change when components get added. Adding more wires, performance went down to about 10fps.

78x39_wires_no_strips.fz.zip

So, this is already quite slow, even without a combinatorial explosion of connections.

While checking, I observed that not all holes are rendered correctly: https://github.com/fritzing/fritzing-app/issues/4192

[KjellMorgenstern]

When testing the registers-and-alu-3.fzz , I get about 10 - 25 fps, full screen. This is on an i9-13900HX , with OpenGL acceleration (will be added as beta feature in Fritzing 1.0.5)

Lets assume an i5-7500 , which was typical in 2017, which is about 150% slower in single core benchmarks, so a factor of 2 or 3. This doesn't fit the 1 fps or even 0.1 fps observed by @xotmatrix . One explanation might be a if there is a performance difference between Windows and Linux builds of Fritzing (it appears so)

[AndrewMatthewman]

Replying to @failiz : the workaround of temporarily cutting strips doesn't fit the use case, I'm afraid, unless the breaks could be selected with the parts and moved around with them as you refine the placement. At that stage of the game, you really just want to be able to pick parts up and move or rotate them without losing your train of thought waiting for the tool to react. Over on the Fritzing Forum, someone has posted with the exact same experience as mine. https://forum.fritzing.org/t/placement-mode-without-circuit-calculation/25520?u=matho Is an improvement of the algorithm on the cards any time soon ? Or does my suggestion of being able to temporarily disable it have merit as a possible way to rapidly get the thorn out of users' sides ?

[KjellMorgenstern]

Fritzing 1.0.5 will likely have at least two significant performance improvements, if there doesn't show a problem last minute: OpenGL for rendering (opt in for now), and a different lookup for scene items by ID.

I checked a board with ~70 parts. One version with 163 unrouted connectors, and one version with everything routed. Both rendered at (8 - 15 fps), with the version with ratsnest lines a bit faster. This is not super fast, but also doesn't seem to be the use case people are complaining about. Also, the above stripboard example didn't show the problems described here.

To answer @AndrewMatthewman : I don't think it makes sense to disable "the calculation", but maybe I was not yet able to reproduce your scenario. Have you checked my 78x39_wires_no_strips.fz.zip board? If possible, could you share a fzz example? Please also let me know which exact version of Fritzing you are using on which Operating System.

[AndrewMatthewman]

I'm running Fritzing 1.0.1 on Ubuntu 20.04.6 LTS. The project dates from around 9 months ago but I didn't get around to trying to make a contribution until now. I was running the same versions at the time. The 78x39_wires_no_strips doesn't exhibit the problem I'm raising. I went back to my backups and pulled out an intermediate version of the design : parts and wires placed, no tracks yet broken, see attached, and you can compare with the final design, also attached. A notable difference is the loading time. The intermediate design stops much longer at the 77% mark. Once open, picking up and moving things is much slower in the intermediate version. project.zip

[KjellMorgenstern]

Thanks @AndrewMatthewman , this example clearly shows a performance problem for Stripboards. I can confirm the delay at 77%.