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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp