kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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