Are there any KiCad nightly (pre 5.1) speed performance concerning?


Just curious,

I use KiCad 6.x, 5.x, and 4.0.7 for my current job. I noted that, for my simple board (~422 pads):
6.0.0, and 5x very slow on:

  1. Read netlist
  2. GUI reaction time
  3. If highlight netlist turn on in schematic, it may layout even way slower very click of the mouse in pcbnew, and eschamatic (even for click on the empty space).

4.0.7 (Default view - extreme case):

  • Out performance on all the items I found above (exclude new nice features ofcouse)!

I also can not find the equivalent “inverted” of “Hide footprint rasnet” feature which help reduce the crowding global rasnets display for place component ( :thinking: )

Is KiCad hitting challenge or limitation of using standard OpenGL?


Just a heads up. There is no version 6 at this point in time. The nightlies that report them selves as version 6 are actually the nightlies that will become version 5.1.0. Version 6 development will only really start when version 5.1 has been released.


I’m almost 100% sure this can’t be the case. AFAIK KiCad uses very basic features of OpenGL and it’s 2D anyways. The problem isn’t about rendering.

You should of course give exact information about your hardware/OS/drivers combination. Have you tried several different machines?

A screencast would be nice. It’s very difficult to know what “slow” or “fast” mean for different persons, and how does it actually happen and look like.



I already provide a relativity of slow and fast which should be testable by anyone. Number of seconds is not a issues. But this is a scaling issue that I see. And most of them seem to relate to OpenGL (Google tell me using vertex in 2D or 3D are having similar performance issue, it is scale by number of vertex)

Check this out:


In any case the problem isn’t in OpenGL. Remember that many modern 3D games are built on top of standard OpenGL. In the bug report the problems seem to be with creating some items, not rendering them.


Hi @nhatkhai

This report is a pathological case of converting a half-tone image to polygons. The actual circuit linked later in the report is now fast (no detectable lag). We keep that bug report open because there are a few things we can do to improve the draw speed even in unusual cases like the half-tone.

Do you have a project that is slow? If so, can you share it either in a bug report or privately? We’ve worked with a number of people to improve the KiCad speed in their specific cases and the results should be noticeable for large projects. If this isn’t the case for your work, we’d still like to improve it.


I try nightly build r11895 build (Nov-27). The speed are as fast as 4.0.7 for:

  1. Read netlist
  2. GUI reaction time

Highlight net on eechema on the empty space took 15 seconds, on the net took 9 seconds.


If you are interested in sharing the project, we can look at improving the speed. Just numbers doesn’t help as the projects I work with do not exhibit this issue.


Loading the PCB indeed spends nearly all of the long wait in ‘’ according to perf.

A quick ‘getting started’ in Linux:

# If you distrust your applications close security sensitive processes.
# This will allow perf to record events without root privileges.
# See also:
sudo sh -c 'echo 1 >/proc/sys/kernel/perf_event_paranoid'

cd sample/

# Record a session opening the file.
# 10kHz is a lot, can be reduced at risk of missing smaller events.
perf record -F 10000 -g -- pcbnew sample.kicad_pcb
# Optionally close the security hole again:
# sudo sh -c 'echo 3 >/proc/sys/kernel/perf_event_paranoid'
perf script > pcbnew.perf

cd {someplace}/
git clone
cd FlameGraph/

# Better consult the README, but here is the TL;DR:
./ {...}/sample/pcbnew.perf > pcbnew.folded
./ pcbnew.folded > pcbnew.svg

# Then open the SVG flame graph in your default viewer, for example:
xdg-open pcbnew.svg

There is quite a bit more possible with perf, especially running debug builds. There is apparently also a GUI called ‘hotspot’, haven’t tried it yet.


@Seth_h here is a distorted version. It create from 4.0.7. So when open with the 5.x, don’t try to remap, just click on the close. Then you can check out how slow is the net highlight would be in the hierarchy sheet. (18.9 KB)


I’ve open the file but can’t recreate any lag issues. It is possible that your issue is system specific.

It would be good to post the project and a video of the issue to the bug tracker. But don’t ask people to skip re-mapping. I skipped it for the video I posted but you can’t skip the remap and expect to work with a KiCad project, so it’s a bit of a non-starter for fixing bugs.


Here is the video and report on bug track system:


Here is a screen grab of nhatkhai’s bug report link on the developers forum:

Anyone else think there just might be a problem with this?


Not sure what you are trying to get at, Sprig. A screen capture (timeline snapshot) can’t demonstrate the issue that he is demonstrating here (lag in net highlight, that Wane even confirmed).