kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Interesting. It _is_ much, much faster on the release build.

I'm sorry, but I think you're wrong here - debug builds NEED to be
usable, so developers will actually do significant amounts of real work
with kicad in an environment where they can track down any issues they
have with it. I still consider this a performance bug, but this is
definitely a pointer in the right direction to solving it.

Not sure why it's unusable on Windows, it certainly isn't anywhere else.
i'm not willing to spend a lot of time solving Windows problems though.


On Fri, Aug 12, 2016 at 08:06:11PM +0200, jp charras wrote:
> Le 12/08/2016 à 19:32, Chris Pavlina a écrit :
> > Hm, debug or release? I don't recall from looking through the netlist
> > code whether it had any major bits switched off in release builds or
> > not. I'm pretty much always running on a debug build.
> 
> Release build.
> 
> I don't think there are many bits switched on/off in debug/release builds in netlist calculations.
> However, fixing a time issue in debug mode is not the same as fixing a bad algorithm.
> Kicad in debug mode (this is not surprising) is slower than in release mode.
> This is especially true on Windows (near not usable, even to open a file selection dialog)
> (A pcbnew binary file is near 1Gbyte size)
> You cannot take a decision from a debug build.
> 
> From my point of view, a better algorithm could be (I am saying: could be):
> calculate sub netlists (one by sheet) and after merge sub netlists.
> 
> On of advantage of this approach is the fact when you are working on a sheet (and modifying it), the
> other subnetlists are not modified.
> If the algorithm is fast enough, highlight a connection in the schematic could be made possible on
> the fly.
> 
> > 
> > On Fri, Aug 12, 2016 at 07:09:37PM +0200, jp charras wrote:
> >> Le 12/08/2016 à 18:26, Chris Pavlina a écrit :
> >>> Ah, no - I got a bit off scope there, I'm talking about the whole
> >>> project.  Generating the netlist in eeschema is very slow, which means
> >>> sch->pcb sync is slow. Not necessarily a task for you specifically, I'm
> >>> just kind of enumerating the bits where kicad's been annoying me on this
> >>> project.
> >>> :)
> >>
> >> Are you sure ?
> >> I downloaded and tested your motherboard project.
> >> Building the netlist is very fast (less than 1 second on my computer).
> >> sch->pcb sync takes roughly 1s.
> >>
> >> only the DRC is time consuming because you have 41000 track segments.
> >>
> 
> Perhaps the number of segments to approximate an arc could be smaller in track/diff pair length
> adjust algo.
> 
> -- 
> Jean-Pierre CHARRAS