KiCad

Bug #1753224
Comment #8

Comment 8 for bug 1753224

Revision history for this message

Jeff Young (jeyjey) wrote on 2018-03-05: Re: [Bug 1753224] Re: pcbnew: Zones->Fill All is became so slow for complex boards

Hi Tom,

I think you perhaps misunderstood my comment.

I wasn’t asking how to bump up the number of segments; I’ve already done that in
DRAWSEGMENT::TransformShapeWithClearanceToPolygon()

Eldar’s bisect showed that the polygon change killed zone filling performance, not the parallelism issue.

(I did re-instate pooled-thread zone-filling, but my guess is that Eldar is going to find that it doesn’t help this case.)

Is there something order-n-squared in the zone filling for the number of segments in a polygon? It sounds like it’s gone from ~4 seconds to ~1000 seconds.

Hmm… it just occurs to me that the new segment-calculating algorithm assumes an arc with a substantial sweep. (It bases the number of segments on the arc radius.) A very flat (large radius) but short arc (small sweep) would end up with a whole lot of segments.

Eldar, what’s the radius on your board edge?

Cheers,
Jeff.

> On 5 Mar 2018, at 10:15, Tomasz Wlostowski <email address hidden> wrote:
>
> Hey,
>
> I guess it was related to the change by Jeff (rewrite of ZONE_FILLER to
> use std::thread instead of OpenMP) where parallelization was list.
>
> @Eldar: now that John brought back parallel threading, could you test
> the latest nightly and see if the speed is back?
>
> @Jeff: Sure. Have a look at SHAPE_ARC::ConvertToPolyline(). It
> calculates the number of necessary segments based on the required
> accuracy (default = 1% = 0.01).
>
> Tom
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1753224
>
> Title:
> pcbnew: Zones->Fill All is became so slow for complex boards
>
> Status in KiCad:
> New
>
> Bug description:
> After some updates Zone filling for complex boards became so slow.
>
> Application: kicad
> Version: 5.0.0-rc2-dev-unknown-aeae32b~62~ubuntu17.10.1, release build
> Libraries:
> wxWidgets 3.0.3
> libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) librtmp/2.3
> Platform: Linux 4.13.0-36-generic x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.62.0
> Curl: 7.55.1
> Compiler: GCC 7.2.0 with C++ ABI 1011
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1753224/+subscriptions

Hi Tom,

I think you perhaps misunderstood my comment.

I wasn’t asking how to bump up the number of segments; I’ve already done that in 
DRAWSEGMENT::TransformShapeWithClearanceToPolygon()

Eldar’s bisect showed that the polygon change killed zone filling performance, not the parallelism issue.

(I did re-instate pooled-thread zone-filling, but my guess is that Eldar is going to find that it doesn’t help this case.)

Is there something order-n-squared in the zone filling for the number of segments in a polygon?  It sounds like it’s gone from ~4 seconds to ~1000 seconds.

Hmm… it just occurs to me that the new segment-calculating algorithm assumes an arc with a substantial sweep.  (It bases the number of segments on the arc radius.)  A very flat (large radius) but short arc (small sweep) would end up with a whole lot of segments.

Eldar, what’s the radius on your board edge?

Cheers,
Jeff.

> On 5 Mar 2018, at 10:15, Tomasz Wlostowski <1753224@bugs.launchpad.net> wrote:
> 
> Hey,
> 
> I guess it was related to the change by Jeff (rewrite of ZONE_FILLER to
> use std::thread instead of OpenMP) where parallelization was list.
> 
> @Eldar: now that John brought back parallel threading, could you test
> the latest nightly and see if the speed is back?
> 
> @Jeff: Sure. Have a look at SHAPE_ARC::ConvertToPolyline(). It
> calculates the number of necessary segments based on the required
> accuracy (default = 1% = 0.01).
> 
> Tom
> 
> -- 
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1753224
> 
> Title:
>  pcbnew: Zones->Fill All is became so slow for complex boards
> 
> Status in KiCad:
>  New
> 
> Bug description:
>  After some updates Zone filling for complex boards became so slow.
> 
>  Application: kicad
>  Version: 5.0.0-rc2-dev-unknown-aeae32b~62~ubuntu17.10.1, release build
>  Libraries:
>      wxWidgets 3.0.3
>      libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) librtmp/2.3
>  Platform: Linux 4.13.0-36-generic x86_64, 64 bit, Little endian, wxGTK
>  Build Info:
>      wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
>      Boost: 1.62.0
>      Curl: 7.55.1
>      Compiler: GCC 7.2.0 with C++ ABI 1011
> 
>  Build settings:
>      USE_WX_GRAPHICS_CONTEXT=OFF
>      USE_WX_OVERLAY=OFF
>      KICAD_SCRIPTING=ON
>      KICAD_SCRIPTING_MODULES=ON
>      KICAD_SCRIPTING_WXPYTHON=ON
>      KICAD_SCRIPTING_ACTION_MENU=ON
>      BUILD_GITHUB_PLUGIN=ON
>      KICAD_USE_OCE=ON
>      KICAD_SPICE=ON
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1753224/+subscriptions