Re: [Kicad-developers] Must tracks & vias of the same net be contiguous?

2018-04-03 Thread Jeff Young 
More data:

1) The double SynchronizeNetsAndNetClasses() costs almost nothing.  We should 
leave it.

2) I did some testing having removed the second call to BuildConnectivity().  
It’s definitely faster; may or may not be risky.

3) I solved the insert performance penalty.  (Since files are /mostly/ in the 
right order, doing an insertion sort from the back is very fast.)

Thoughts on (2) appreciated.

Cheers,
Jeff.


> On 3 Apr 2018, at 18:58, Jeff Young  wrote:
> 
> We also call SynchronizeNetsAndNetClasses() twice (once in 
> NETINFO_LIST::buildListOfNets() and once immediately after returning from it).
> 
> 
>> On 3 Apr 2018, at 15:41, Jeff Young > 
>> wrote:
>> 
>> With the fix, TRACK::GetBestInsertPoint(BOARD*) takes 6.2% of a file load on 
>> a reasonably dense board.  
>> 
>> As points of comparison, BOARD::BuildConnectivity() takes 16.2% and 15.5%, 
>> and PCB_EDIT_FRAME::ReFillLayerWidget() 3.3%.
>> 
>> (We could of course have a faster and more resilient load if we added 
>> GetBestInsertPoint() but stopped calling BuildConnectivity() twice*.)
>> 
>> Cheers,
>> Jeff.
>> 
>> * Once from OpenProjectFiles() and once from OpenProjectFiles()/SetBoard().
>> 
>> 
>>> On 3 Apr 2018, at 14:48, Jeff Young >> > wrote:
>>> 
>>> The track/via insertion routines have two modes: blind-append and 
>>> insert-where-appropriate.  The board parser current relies on the file 
>>> being correct and uses append.  Changing it to insert fixes the bug.
>>> 
>>> I like this change because it makes us more resilient, and because it will 
>>> fix any other (unknown) bugs due to tracks not being grouped properly.
>>> 
>>> I don’t like this change because it will make board loading slower.
>>> 
>>> Another idea would be to keep track of tracks/vias as they come in, and 
>>> only do the sort if we find some out of order.  That’s definitely more 
>>> risky, though, and may not be much faster.
>>> 
>>> I’ll do some timings on a large board….
>>> 
 On 3 Apr 2018, at 14:36, Wayne Stambaugh > wrote:
 
 On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
> On 03/04/18 15:13, Jeff Young wrote:
>> The clean-up algorithms depend on tracks & vias assigned to the same net 
>> to be grouped in the segment list.  Is that supposed to be guaranteed?
> 
> It is/used to be like this (there was/is a special sorting function,
> called at least in the TRACK_CLEANER). I would however rewrite the
> overlapping segment merging algorithm to not rely on the order of
> segments in the data structure. If nobody opposes I could give this a try.
> 
> Tom
 
 How much risk are we looking at?  Wouldn't it be more prudent to just
 ensure the sorting is performed before performing the track clean
 operation?  I would rather avoid creating any new issues this close to
 v5.  If we cannot avoid making the change, then we may just have to deal
 with it but I would rather that be the last option.
 
> 
> 
>> 
>> (I have a file where it is not the case.)
 
 I thought the sorting was always performed so that segments and vias
 would always be grouped by their net.  I'm not sure how a board file was
 created with an ungrouped segment.  @JP, care to comment on this?
 
>> ___
>> 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 
>> 
>> 
> 
> 
> ___
> 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 
> 
> 
 
 ___
 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 
 
>>> 
>>> 
>>> ___
>>> Mailing list:

Re: [Kicad-developers] Must tracks & vias of the same net be contiguous?

2018-04-03 Thread Jeff Young 
We also call SynchronizeNetsAndNetClasses() twice (once in 
NETINFO_LIST::buildListOfNets() and once immediately after returning from it).


> On 3 Apr 2018, at 15:41, Jeff Young  wrote:
> 
> With the fix, TRACK::GetBestInsertPoint(BOARD*) takes 6.2% of a file load on 
> a reasonably dense board.  
> 
> As points of comparison, BOARD::BuildConnectivity() takes 16.2% and 15.5%, 
> and PCB_EDIT_FRAME::ReFillLayerWidget() 3.3%.
> 
> (We could of course have a faster and more resilient load if we added 
> GetBestInsertPoint() but stopped calling BuildConnectivity() twice*.)
> 
> Cheers,
> Jeff.
> 
> * Once from OpenProjectFiles() and once from OpenProjectFiles()/SetBoard().
> 
> 
>> On 3 Apr 2018, at 14:48, Jeff Young > 
>> wrote:
>> 
>> The track/via insertion routines have two modes: blind-append and 
>> insert-where-appropriate.  The board parser current relies on the file being 
>> correct and uses append.  Changing it to insert fixes the bug.
>> 
>> I like this change because it makes us more resilient, and because it will 
>> fix any other (unknown) bugs due to tracks not being grouped properly.
>> 
>> I don’t like this change because it will make board loading slower.
>> 
>> Another idea would be to keep track of tracks/vias as they come in, and only 
>> do the sort if we find some out of order.  That’s definitely more risky, 
>> though, and may not be much faster.
>> 
>> I’ll do some timings on a large board….
>> 
>>> On 3 Apr 2018, at 14:36, Wayne Stambaugh >> > wrote:
>>> 
>>> On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
 On 03/04/18 15:13, Jeff Young wrote:
> The clean-up algorithms depend on tracks & vias assigned to the same net 
> to be grouped in the segment list.  Is that supposed to be guaranteed?
 
 It is/used to be like this (there was/is a special sorting function,
 called at least in the TRACK_CLEANER). I would however rewrite the
 overlapping segment merging algorithm to not rely on the order of
 segments in the data structure. If nobody opposes I could give this a try.
 
 Tom
>>> 
>>> How much risk are we looking at?  Wouldn't it be more prudent to just
>>> ensure the sorting is performed before performing the track clean
>>> operation?  I would rather avoid creating any new issues this close to
>>> v5.  If we cannot avoid making the change, then we may just have to deal
>>> with it but I would rather that be the last option.
>>> 
 
 
> 
> (I have a file where it is not the case.)
>>> 
>>> I thought the sorting was always performed so that segments and vias
>>> would always be grouped by their net.  I'm not sure how a board file was
>>> created with an ungrouped segment.  @JP, care to comment on this?
>>> 
> ___
> 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 
> 
> 
 
 
 ___
 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 
 
 
>>> 
>>> ___
>>> 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 
>>> 
>> 
>> 
>> ___
>> 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 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   :

Re: [Kicad-developers] Must tracks & vias of the same net be contiguous?

2018-04-03 Thread Jeff Young 
With the fix, TRACK::GetBestInsertPoint(BOARD*) takes 6.2% of a file load on a 
reasonably dense board.  

As points of comparison, BOARD::BuildConnectivity() takes 16.2% and 15.5%, and 
PCB_EDIT_FRAME::ReFillLayerWidget() 3.3%.

(We could of course have a faster and more resilient load if we added 
GetBestInsertPoint() but stopped calling BuildConnectivity() twice*.)

Cheers,
Jeff.

* Once from OpenProjectFiles() and once from OpenProjectFiles()/SetBoard().


> On 3 Apr 2018, at 14:48, Jeff Young  wrote:
> 
> The track/via insertion routines have two modes: blind-append and 
> insert-where-appropriate.  The board parser current relies on the file being 
> correct and uses append.  Changing it to insert fixes the bug.
> 
> I like this change because it makes us more resilient, and because it will 
> fix any other (unknown) bugs due to tracks not being grouped properly.
> 
> I don’t like this change because it will make board loading slower.
> 
> Another idea would be to keep track of tracks/vias as they come in, and only 
> do the sort if we find some out of order.  That’s definitely more risky, 
> though, and may not be much faster.
> 
> I’ll do some timings on a large board….
> 
>> On 3 Apr 2018, at 14:36, Wayne Stambaugh  wrote:
>> 
>> On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
>>> On 03/04/18 15:13, Jeff Young wrote:
 The clean-up algorithms depend on tracks & vias assigned to the same net 
 to be grouped in the segment list.  Is that supposed to be guaranteed?
>>> 
>>> It is/used to be like this (there was/is a special sorting function,
>>> called at least in the TRACK_CLEANER). I would however rewrite the
>>> overlapping segment merging algorithm to not rely on the order of
>>> segments in the data structure. If nobody opposes I could give this a try.
>>> 
>>> Tom
>> 
>> How much risk are we looking at?  Wouldn't it be more prudent to just
>> ensure the sorting is performed before performing the track clean
>> operation?  I would rather avoid creating any new issues this close to
>> v5.  If we cannot avoid making the change, then we may just have to deal
>> with it but I would rather that be the last option.
>> 
>>> 
>>> 
 
 (I have a file where it is not the case.)
>> 
>> I thought the sorting was always performed so that segments and vias
>> would always be grouped by their net.  I'm not sure how a board file was
>> created with an ungrouped segment.  @JP, care to comment on this?
>> 
 ___
 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
 
>>> 
>>> 
>>> ___
>>> 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
>>> 
>> 
>> ___
>> 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
> 
> 
> ___
> 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

___
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

Re: [Kicad-developers] Must tracks & vias of the same net be contiguous?

2018-04-03 Thread Jeff Young 
The track/via insertion routines have two modes: blind-append and 
insert-where-appropriate.  The board parser current relies on the file being 
correct and uses append.  Changing it to insert fixes the bug.

I like this change because it makes us more resilient, and because it will fix 
any other (unknown) bugs due to tracks not being grouped properly.

I don’t like this change because it will make board loading slower.

Another idea would be to keep track of tracks/vias as they come in, and only do 
the sort if we find some out of order.  That’s definitely more risky, though, 
and may not be much faster.

I’ll do some timings on a large board….

> On 3 Apr 2018, at 14:36, Wayne Stambaugh  wrote:
> 
> On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
>> On 03/04/18 15:13, Jeff Young wrote:
>>> The clean-up algorithms depend on tracks & vias assigned to the same net to 
>>> be grouped in the segment list.  Is that supposed to be guaranteed?
>> 
>> It is/used to be like this (there was/is a special sorting function,
>> called at least in the TRACK_CLEANER). I would however rewrite the
>> overlapping segment merging algorithm to not rely on the order of
>> segments in the data structure. If nobody opposes I could give this a try.
>> 
>> Tom
> 
> How much risk are we looking at?  Wouldn't it be more prudent to just
> ensure the sorting is performed before performing the track clean
> operation?  I would rather avoid creating any new issues this close to
> v5.  If we cannot avoid making the change, then we may just have to deal
> with it but I would rather that be the last option.
> 
>> 
>> 
>>> 
>>> (I have a file where it is not the case.)
> 
> I thought the sorting was always performed so that segments and vias
> would always be grouped by their net.  I'm not sure how a board file was
> created with an ungrouped segment.  @JP, care to comment on this?
> 
>>> ___
>>> 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
>>> 
>> 
>> 
>> ___
>> 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
>> 
> 
> ___
> 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


___
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

Re: [Kicad-developers] Must tracks & vias of the same net be contiguous?

2018-04-03 Thread Wayne Stambaugh 
On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
> On 03/04/18 15:13, Jeff Young wrote:
>> The clean-up algorithms depend on tracks & vias assigned to the same net to 
>> be grouped in the segment list.  Is that supposed to be guaranteed?
> 
> It is/used to be like this (there was/is a special sorting function,
> called at least in the TRACK_CLEANER). I would however rewrite the
> overlapping segment merging algorithm to not rely on the order of
> segments in the data structure. If nobody opposes I could give this a try.
> 
> Tom

How much risk are we looking at?  Wouldn't it be more prudent to just
ensure the sorting is performed before performing the track clean
operation?  I would rather avoid creating any new issues this close to
v5.  If we cannot avoid making the change, then we may just have to deal
with it but I would rather that be the last option.

> 
> 
>>
>> (I have a file where it is not the case.)

I thought the sorting was always performed so that segments and vias
would always be grouped by their net.  I'm not sure how a board file was
created with an ungrouped segment.  @JP, care to comment on this?

>> ___
>> 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
>>
> 
> 
> ___
> 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
> 

___
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

Re: [Kicad-developers] Must tracks & vias of the same net be contiguous?

2018-04-03 Thread Tomasz Wlostowski 
On 03/04/18 15:13, Jeff Young wrote:
> The clean-up algorithms depend on tracks & vias assigned to the same net to 
> be grouped in the segment list.  Is that supposed to be guaranteed?

It is/used to be like this (there was/is a special sorting function,
called at least in the TRACK_CLEANER). I would however rewrite the
overlapping segment merging algorithm to not rely on the order of
segments in the data structure. If nobody opposes I could give this a try.

Tom


> 
> (I have a file where it is not the case.)
> ___
> 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
> 


___
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