kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 12/08/2017 à 22:15, Maciej Suminski a écrit :
> 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.
> 
> 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.
> 
> 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?
> 
> 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?
> 
> Regards,
> Orson
> 
> 1. https://github.com/c4puter/motherboard.git

This was made to speed up netlist and connection calculations in the early time of Pcbnew.
(There was no support of wxString and std::string, therefore comparing 2 strings was not as easy and
not as fast as comparing 2 numbers).

I am thinking the long pin number support can be now safely removed without any problem and the code
will be clearer.

I don't think the file format changes, if the pad name is restricted to 4 ASCII7 chars, like now.
The file format changes only if the pad name is free (any UTF8 char, any length).
However a full free name/pin number can be not compatible with netlists:
see Spice and other formats for instance.
Moreover any non ASCII7 char will create problems in X2 Gerber files (only ASCII7 chars are allowed
in Gerber files).

But this is an other problem (and besides, I am not sure a free pad name is very useful: all
footprints use only digits and A...Z chars in Pad names).

-- 
Jean-Pierre CHARRAS