Teardrops destroy fill performance on large projects

Description

I have a big project, but refilling zones is still a 5 seconds job. However, after adding teardrops, it takes a full 6 minutes. I also tried this once on another machine with many more cores but it took over 7 minutes, so it might point to some multithreading thing breaking. It seems weird that fewer cores would perform better, especially as the system monitor app shows all cores active

Test performed with straight line teardrops. The addition of teardrops (and filling zones afterwards) also meant that the project file size goes from 27MB to 39MB. I did run it once on curved line teardrops, and it took 8 minutes with a file size of 47MB. All test were run on a system with the ryzen 7 pro 7840u cpu, except the one that was on a machine with more cores, which has a Ryzen AI 9 HX 370

EDIT: after posting I saw that there was an option to increase the maximum allowed deviation in curves. increasing it from 0.005 to 0.05mm, made fill time 30 seconds longer, which is the opposite of what I'd expect.

Steps to reproduce

  1. Have a big project (I got almost 2000 components, over 6000 pads, almost 3000 vias and 17000 track segments.
  2. Add teardrops
  3. Run fill zones

KiCad Version

Application: KiCad x86_64 on x86_64

Version: 9.0.2, release build

Libraries:
	wxWidgets 3.2.8
	FreeType 2.13.3
	HarfBuzz 9.0.0
	FontConfig 2.15.0
	libcurl/8.14.1 OpenSSL/3.3.3 zlib/1.3.1 libidn2/2.3.7 libpsl/0.21.5 nghttp2/1.65.0

Platform: Freedesktop SDK 24.08 (Flatpak runtime), 64 bit, Little endian, wxGTK, X11, gnome, wayland
OpenGL: AMD, AMD Radeon 780M (radeonsi, phoenix, LLVM 19.1.7, DRM 3.59, 5.14.0-570.22.1.el9_6.x86_64), 4.6 (Compatibility Profile) Mesa 25.1.3 (git-ba95e694fe)

Build Info:
	Date: Nov 11 2011 11:11:11
	wxWidgets: 3.2.8 (wchar_t,wx containers) GTK+ 3.24
	Boost: 1.88.0
	OCC: 7.9.1
	Curl: 8.14.0
	ngspice: 44.2
	Compiler: GCC 14.3.0 with C++ ABI 1019
	KICAD_IPC_API=ON

Locale: 
	Lang: en_US
	Enc: UTF-8
	Num: 1,234.5
	Encoded кΩ丈: D0BACEA9E4B888 (sys), D0BACEA9E4B888 (utf8)
Edited by Onno Twisk