I also confirm that the KiCad has become slower (10 times or more) since version 6.06. Unfortunately I cannot send the project due to confidentiality issues but I can say that it is a mid-complex design with 6 layers, several copper zones and many many vias to improve thermal behavior…
I run KiCad on a Linux Mint distribution
I can not either send the project, by the same reason. But the design is 4 layers with similar description as your design, gschelotto. Bad enough I have now got back to an old Eagle version, restarted the project/edits from there as it’s currently not possible to do work with this project in Kicad.
The common denominator here seems to be NOT Windows
I just tested it also in windows (via parallells desktop where most other windows applications/for example eagle works very good and fast) and this KiCad project may be even slower in Windows 10/KiCad stops/freezes about every click in windows 10, where I use KiCad 6.0.5…
Update: Hmm, then suddenly it started working pretty well again (windows), not super super fast but probably good enough for this kind of project. 8 seconds for the 4 layers polygons refill now…
… And today I also tested to downgrade to KiCad 6.0.5 in Mac OS Catalina – and it got fast again also there, even faster than Kicad 6.0.5 in Windows 10 /with Parallels (maybe because Parallels also takes some power)!
What happened after 6.05 in the upgrade progress for Mac Os? And did it get very much slower also in both Windows and Linux? Anyone?
Update: Video showing this here
Just for reference: using my freshly build KICAD 6.0.7 on mint 21 “Vanessa” I loaded the named reference OLINUXINO/HARDWARE/A64-OLinuXino at master · OLIMEX/OLINUXINO · GitHub.
After removing the copper areas it took about 12 seconds to rebuild them again.
(AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G × 2, 16 GB RAM).
But what’s the “before” 6.0.7 time?
And compared to 6.0.5 it was?
Good questions, but no answers. I tried to downgrade to 6.0.2 (from the repositories), but here once again the pcb-editor crashes, so except for my own builds I cannot give any other reference.
And here I played with some compile options and found one option quite effective:
by selecting “KICAD_SANITIZE_THREADS” I can increase the fill time for the olimex board from 12 seconds to 3 minutes 20 seconds (!!!).
So it may be worth to check the compilation options.
Thanks HOH, I’m just a simple user who knows nothing about programming/compiling, but I hope this will get fixed/sorted out by those who make the programming for KiCad soon. Or later. Until then, at least, I’m back on Eagle again…
Nevertheless, it would be interesting to compare your KICAD installation with the olimex board for the time for copper filling…
On my pc the recalculation of the zonesw takes about 8 sec in kicad 6.0.7 and 10 sec in kicad 6.99 but an old build of 21/07/2022
Linux Mint 20.3
I’ve installed Linux Mint 20.3 Una. I’ve also tested the A64 olimex board with KiCad 6.0.7 and the performance is quite good. My 6-layer custom design is more complex in the sense of more area (15x25 cm) more (non-regular) copper zones and much more vias and tracks. In this case the KiCad PCB load time with zones recalculation is about 25 seconds…However in KiCad 6.0.5 it had taken less than 4 seconds.
Just to add more information, I download the board and filled up the zones, it took about 23s on my laptop.
Win10
Intel(R) Core™ i7-8565U CPU @ 1.80GHz
RAM 16,0 GB
GeForce MX250
Application: KiCad (64-bit)
Version: (6.0.6-1-gc8a1c5c707), release build
Libraries:
wxWidgets 3.1.6
libcurl/7.82.0-DEV Schannel zlib/1.2.12
Platform: Windows 10 (build 19043), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Date: Jun 18 2022 07:32:04
wxWidgets: 3.1.6 (wchar_t,wx containers)
Boost: 1.79.0
OCC: 7.6.0
Curl: 7.82.0-DEV
ngspice: 37
Compiler: Visual C++ 1929 without C++ ABI
Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON
EDIT: And it took around 5 seconds on v5, that in general felt snappier …
Application: Pcbnew
Version: (5.1.10)-1, release build
Libraries:
wxWidgets 3.0.5
libcurl/7.71.0 OpenSSL/1.1.1g (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.73.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.71.0
Compiler: GCC 10.2.0 with C++ ABI 1014
Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
Hi, where is that test board available for download, to test to fill the zones also here (in version 6.0.5, 6.0.7, and the latest 6.9.9 nightly build)? I visited gitlab a few days back but could not find anything which looked like a board project.
@HOH wrote a link to it a couple of post back, it is from the company Olimex and it is hosted in their GitHub, but is freely available
I used this tool, to download the folder directly and not the complete repository, here a link:
https://minhaskamal.github.io/DownGit/#/home?url=https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A64-OLinuXino/2. Older hardware revisions/A64-OLinuXino hardware revision E
Thanks for the download link. Just tested to refill the zones for 6 layers here (OSX Catalina) in KiCad version 6.0.5, 6.0.7, and 6.9.9 nightly build – all was fast, no real difference between the KiCad Versions, about 5 seconds fill time each.
There seem to be a lot of difficulties reported in this thread. But until there is an example that can be shared with the developers, we won’t be able to address/fix anything. We frequently test with complex boards that we have access to. If your use case is slow, then we would need to see that use case or a simplified version of it to recreate and fix your specific issue.
One good thing I just happened to notice in this was that I was able to open a project in 6.0.5 which was saved in 6.0.7! This is the way you should work about it all the time! – to make it possible to open newer projects also in older software versions (just as Eagle always made it) in case it’s problems/bugs in updates of the software, that way we can all open the projects also in the old software and continue the project until the software updates are fixed!