Increase in runtime and memory usage in v8.0.3

[davide]

Has anyone notice a significant difference in runtime and memory usage in v8.0.3?
I certainly have when compared to v7.0.10.
Granted I have a small amount of RAM (16 GB) on a Win10 Lenovo laptop, but I never had the lag and memory cap issues compared to v7.0.x.
Even the smallest of things like Saving, Undo, Highlighting, etc. take much longer to complete. I have yet to complete an DRC on my layout. The checker gets to the check track and via clearance stage, gets about halfway through and doesn’t respond further as 99% of the memory is used. Even letting it run overnight (hoping that some virtual memory may help) fails to complete.

[paulvdh]

KiCad should not use so much memory.

To give some reference, as a simple test I start KiCad with the A64-Olinuxino board (Raspi like PC, available on github)

100MiB Project only.
400MiB Also schematic opened.
600MiB Also PCB editor opened.
1GiB Also the 3D viewer opened, and doing some trivial changes (memory footprint grows when working on a PCB).

Running DRC (ERC is for the schematic, not the layout) takes about 8s on my AMD 5600G.

Application: KiCad x86_64 on x86_64

Version: 8.0.3-8.0.3-0~ubuntu20.04.1, release build

Libraries:
	wxWidgets 3.2.2
	FreeType 2.10.1
	HarfBuzz 2.6.4
	FontConfig 2.13.1
	libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3

Platform: Linux Mint 20.3, 64 bit, Little endian, wxGTK, X11, xfce, x11
OpenGL: AMD, AMD RENOIR (DRM 3.42.0, 5.15.0-113-generic, LLVM 12.0.0), 4.6 (Compatibility Profile) Mesa 21.2.6

Build Info:
	Date: Jun  4 2024 12:41:44
	wxWidgets: 3.2.1 (wchar_t,wx containers) GTK+ 3.24
	Boost: 1.71.0
	OCC: 7.6.3
	Curl: 7.68.0
	ngspice: 42
	Compiler: GCC 9.4.0 with C++ ABI 1013

Build settings:

[davide]

I like how you have a breakdown for memory resources on each application.
My project is a little bigger than a Raspi. An FMC mezzanine board for DDR4 interface. Many layers (18) with all nets being tuned. Even in v7.0.10, my DRC checks were close to 10 minute runtimes, but at least they finished. I even used a system with enormous resources on it which resulted in 5-7 minute runtimes.

[paulvdh]

Do you get comparable results to me when you load the A64 Olinuxino Rev-C (From Gitlab) If the results are similar then at least it’s not a problem with your setup.

[davide]

No, I have not. I may do that when the bandwidth allows.

For now, just curious if others are experiencing what I am.

[marekr]

@davide

I even used a system with enormous resources on it which resulted in 5-7 minute runtimes.

Sounds like a bug tbh. Unique designs can encounter unique performance problems

[davide]

There is nothing proprietary about my design and I’d be willing to offer it as a testcase.
LMK

And…if it helps CERN development, this board will be used for beam testing. Mostly heavy ion with a little neutron and proton too

[paulvdh]

@marekr

Unique designs cause problems

This triggers a memory from the Solderless Breadboard from Architeuthis Flux I once had a look at that project, and found that KiCad was responding extremely slow. After some time experimenting I discovered it was caused by the logo on the silkscreen layer. When I removed that single picture, the project was responsive again in KiCad.

[marekr]

@davide

There is nothing proprietary about my design and I’d be willing to offer it as a testcase.

Can you open a gitlab issue detailing performance issues with your design? You can attach the design there. You can also mark the issue confidential so only developers see it if you want.

Issues · KiCad / KiCad Source Code / kicad · GitLab

[davide]

Interesting.
While I do have a logo to add, it is not incorporated yet. I did add it at one time and was hoping to see it in the 3D viewer with everything else, but it didn’t show in the viewer. I removed it (temporarily).

[davide]

Sure. I’ll probably do it later today. Thanks

[paulvdh]

I am not implying that your performance has something do do with a logo. I only mentioned it as an example that a single object can cause performance problems.

Maybe I should create an issue for that solderless breadboard too (or at least the logo in that project).

(Edit: More details about this in the thread below)

Performance issue with zone filling, and not getting results

@ qu1ck, oops, silly me, forgot about that button, it works for me now too, updated my opening post. And the plot thickens… As a test, I deleted all the zones, and divided the PCB into 4 (not overlapping) zones by snapping corner points of 4 zones together. All 4 zones are set to In1.Cu, In2.Cu and B.Cu layers, and the zones now fill in 15s. (In retrospect, there was no big zone on F.Cu) [image] Adding the F.Cu layer and time increases again to two minutes. [A little bit later…] Examinin…

[davide]

I did not take it as an implication. Just thought that something trivial like that could cause a problem. We’re good

[marekr]

That’s absolutely not his problem by description in a million years.

[davide]

Gitlab case has been created. It was unclear to me if the files I uploaded made it. If you can let me know, I will correct it if necessary.

[BlackCoffee]

@marekr

hat’s absolutely not his problem

Another thing that “won’t be his problem” but, posted for Mac users… On Mac, select the Application, Get_Info and set ‘Prevent AppNap’. This makes a world of difference for Apps that feature this (for example, when calculating lot’s of data and time exceeds the system ‘wait’ setting. If you/users use FreeCAD and a Mac, you may already know about this…

[davide]

The files in Gitlab now…

[davide]

Due to the lack of physical space on this laptop, I have very few apps installed. Also keep in mind that I was using v7.0.10 without issue.

[davide]

Here is my latest C++ runtime libs (which look to be current):

[davide]

I appreciate the offer
Let me look at my Carbon and see if it is compatible and has an extra SODIMM slot. As this is very slim, I’m guessing that it only has one.