Stacking up the BOARD_COMMITs was most of the problem. Thanks for the tip, Seth!
On Tue, Mar 20, 2018 at 9:52 AM, Jon Evans <[email protected]> wrote: > I will try Seth's performance idea to see if I can make a > minimally-intrusive improvement there. > I was proposing it as an option because (a) it changes the way DRC has > always worked, and maybe some people don't like seeing a million > overlapping errors if they have a track with many segments that all > conflict with a pad, for example, and (b) because it is currently *really* > slow, like 10x slower, on large designs. > > -Jon > > On Tue, Mar 20, 2018 at 9:46 AM, Jeff Young <[email protected]> wrote: > >> Do we really want a user preference for this? From first blush I'd think >> it should report all errors all the time. (And the fact that it doesn’t >> strikes me as enough of a bug to want it fixed for 5.0.) >> >> I think both Seth’s performance ideas are worth pursuing, but probably in >> 6.0…. >> >> Cheers, >> Jeff. >> >> >> On 20 Mar 2018, at 03:38, Seth Hillbrand <[email protected]> >> wrote: >> >> Hi Jon- >> >> I don't see anything inherently problematic here. Works as advertised >> and seems to be minimally invasive. >> >> I suspect that your primary speed bump is the BOARD_COMMIT being called >> on each segment error marker. You might get bang for the buck by >> conditionally starting a BOARD_COMMIT at the beginning of DoTrackDRC in the >> case where you are reporting all errors and commit.add the markers rather >> than calling addMarkerToPcb(). Then push at the end of the function. >> Also, do we need to create undo entries for the DRC markers? I suspect not >> but I could be overlooking something. >> >> All that said, this is a useful addition and definitely speeds up error >> resolution on problematic boards. >> >> -S >> >> 2018-03-19 19:58 GMT-07:00 Jon Evans <[email protected]>: >> >>> I'd like some eyes on this before I push it, since it's a rather >>> significant change. >>> >>> I have added a (disabled by default) option to report all DRC issues on >>> each tested track. The current behavior is to stop at the first error, >>> which means that the only way to get a full DRC report is to fix errors one >>> by one. >>> >>> See: https://bugs.launchpad.net/kicad/+bug/1754442 >>> >>> I tried to make this change as minimal as possible because I know the >>> DRC code is a target for refactoring after 5.0. The performance of the >>> current system is not great, and I can think of several optimizations that >>> would help a lot, but I think they would touch too much to be a part of >>> 5.0. Fortunately there is progress reporting on this step, so at least >>> users will have feedback. >>> >>> -Jon >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
