kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 8/12/2017 4:15 PM, Maciej Suminski wrote:
> Hi,
> 
> TL;DR: I seek your input regarding support for long pin numbers and pad
> names. Perhaps it might not be perceived as a frequently used feature,
> but the four characters restriction for names is an obstacle for import
> plugins.

I am fine with this change if it is required to allow the Eagle
schematic plugin to work properly as much as I don't want to change the
current schematic file format.  We will just have to bite the bullet to
include what I consider an important feature given the current Eagle
licensing issues.

> 
> As I understand, the decision to use an union of integer and char[4] for
> pin numbers and pad names was to speed up comparisons. On the other
> hand, there are many places that copy a pin number/pad name to a
> temporary wxString (e.g. LIB_PIN::PinStringNum(),
> D_PAD::StringPadName()), instead of referencing the names directly, so
> the fast comparison benefit might be reduced in other places. Another
> minor thing is IMHO the code in the current form is more concise and
> easier to read.

Your changes are definitely more readable.

> 
> I decided to instrument the code to see the change impact. I picked the
> parts that perform many comparisons: for pins it is loading a library,
> as on every LIB_PART::AddDrawItem() the items are sorted, and for boards
> it is reloading a netlist that calls MODULE::FindPadByName() frequently.
> 
> * Loading libraries (time to load a subset of standard KiCad libraries;
> benchmarking LIB_PIN::compare()):
>     w/o long pin number support: ~8 s
>     with long pin number support: ~9 s
> 
> You can notice a ~12% penalty for the long pin number support. Later I
> am going to investigate whether we need to sort LIB_ITEMs as often as we
> do currently, but it is another topic.
> 
> * Importing a netlist to an empty board (time to import c4puter
> motherboard [1] netlist; benchmarking MODULE::FindPadByName()):
>     with long pin number support: ~3.2 s
>     w/o long pin number support: ~3.3 s
> 
> In this case the performance drop is ~3%, but the time difference is so
> low that the profile timer resolution can be at play.
> 
> The price to pay for the feature is a file format version bump, both for
> eeschema and pcbnew. Are we okay with that?

I think we can live with the relatively small performance hit for better
Eagle import support.  Are you sure the board file format need to be
bumped?  There are no code changes to either the pcb parser or formatter
that I could see.  I do not believe there is any risk of pad numbers
from a board being pushed back to the schematic editor so I'm not sure a
board file revision bump is required.  AFAIK there is no schematic file
version check nor has there ever been that I am aware of unless we add
one to the legacy schematic plugin so we may need to add it to actually
check the file version.

> 
> Patch 0003 changes D_PAD::{S,G}etPadName() to D_PAD::{S,G}etName(), as
> it seems a bit clearer to me. The drawback is the risk of breaking a
> number of Python plugins that use the old method names. Any thoughts?

I'm fine with this as well.  Hopefully some of the other devs will test
this just to get a feel for any potential issues.

Cheers,

Wayne

> 
> Regards,
> Orson
> 
> 1. https://github.com/c4puter/motherboard.git
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>