kicad-developers team mailing list archive

[Andrew Zonenberg <azonenberg@xxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Apparently most of the run time in processPads() was caused by copying
the RN_NODE_SET "candidates".

I have a one-line patch in my branch
(https://code.launchpad.net/~azonenberg/kicad/drc-patches/+merge/284682)
that changes this copy to a const reference. There's probably room for
bigger speedups but this was a trivial (and significant) optimization.

On 01/02/16 10:33, Andrew Zonenberg wrote:
> Pads on the same net overlapping should not necessarily be a DRC 
> error, consider the case of someone trying to make a D-shaped pad
> by putting a round one on top of a rectangle. Maybe if they're not
> part of the same component?
> 
> Here's some quick performance numbers for the ground net on my
> board.
> 
> processPads took 0.266 sec Update took 0.377 sec processPads took
> 0.275 sec Update took 0.383 sec processPads took 0.293 sec Update
> took 0.403 sec processPads took 0.305 sec Update took 0.413 sec
> 
> So looks like processPads is about 3/4 of the total run time of 
> Update(). Will look into that a little bit and see if there's any 
> obvious speedups.
> 
> On 01/02/16 06:24, Maciej Sumi?ski wrote:
>> Apparently the most expensive part is RN_DATA::processPads()
>> that does collision checks for pads. It handles cases when tracks
>> do not end in the middle of a pad, or when pads overlap (IMHO
>> this should be caught by DRC as an error instead, as pointed out
>> at FOSDEM).
> 
>> If you do not care about mini ratsnest lines when a track ending 
>> and a pad center have different coordinates, then you should be 
>> safe commenting it out (ratsnest_data.cpp:417). There is an idea
>> to improve speed here, but it requires more changes and has to be
>> well planned first.
> 
>> Regards, Orson
> 
>> On 01/31/2016 09:27 PM, Andrew Zonenberg wrote:
>>> When working on a board with a lot of pads, terminating a
>>> trace on a high-fanout net results in a significant (a second
>>> or more) hang of the entire UI. I haven't yet attempted to
>>> figure out what part of the code this hang is in.
>>> 
>>> Steps to reproduce:
>>> 
>>> 1) Open a large board file in pcbnew (I'm testing with 
>>> http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-switch
.
>
>>> 
kic
>>> 
>>> 
> ad_pcb)
>>> in GAL mode. The hang does not appear to be reproducible in 
>>> legacy.
>>> 
>>> 2) Start drawing a track on a high-fanout net (GND is a good 
>>> example)
>>> 
>>> 3) Performance should be normal when the track is started and 
>>> during drawing, but when you click on a pad to terminate the 
>>> track pcbnew hangs .
>>> 
>>> Anybody with PNS experience (Orson, Tomasz, etc) care to 
>>> investigate thi s?
>>> 
>>> _______________________________________________ Mailing list: 
>>> https://launchpad.net/~kicad-developers Post to     : 
>>> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe : 
>>> https://launchpad.net/~kicad-developers More help   : 
>>> https://help.launchpad.net/ListHelp
>>> 
> 
> 
> 
> _______________________________________________ Mailing list:
> https://launchpad.net/~kicad-developers Post to     :
> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJWr+OnAAoJEDRhermzHH18xjcP/R3PEm3qdUcFsWzLB7/FtX0m
A9AgVU/r9wlojpFluyZDdH2+yWEkofqtRODbNnhn3tcSlLjrLz9hWusimEIzMAq9
rlVVF0ODbih/HS3dpcGj3HVrvnijeSNwbc0y8E54H3p7+zfabIRRqdoYZvbnlZ0d
SYhMzZuNKNtYK8IrQgme8oqLp1aNuPeLSr8Vje36D5vSFLcZ73mIK52+oKKW8xwY
21/I40U9FP6XLzOHnMoYtbQBbvIPgKmEft8veCF1iX1lojELqtC5kdoIDzLkCHya
m2QHmQKlafJMLRYT5+ziDtFq9G/fiVjkz2BRZLCF+lggp1h2hQ8xMkeuQqzmG2Lk
XxYrrFLA5OHQIQ1xU6ZV2cTOhILxL9lwxgow6xAopQOoddiBWAyHYxhp2Vdh1dXa
+/Mn5beXsVIlKdNAngnBSGDyQbu+tyXKh5x4yN5lqX/FypsgAMHs7dwqswroCp0b
FOGMHvFnSPh2YgsS7PQBEuiZHLUhxcTk825T09nDewtNcSp3MvZRJlWAVinLyPQ4
ljBsHAzvJf6z6rbsViFhFsypUD2C543fLPTBsQgfE5dowLv25TR8EFVld1OWmrD0
KbSshlcDnEHH+xyJFIUP/OJ2PC4C50lUVUobmANHPFSqdj4uh3ECBNe2hi+9ZhEx
1CQOMHAeDZ5mpY7iyTmu
=984p
-----END PGP SIGNATURE-----