kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 2/24/2017 11:29 AM, Chris Pavlina wrote:
> Hi all and Wayne,
> 
> Since the addition of SCH_PLUGIN, enumerating all symbols (done by the
> component selector) has become dog slow on Windows and macOS. I've
> tracked this down to the excursion from an alias list to a list of
> strings and back to an alias list, because the only functions SCH_PLUGIN
> provides to access the aliases are by name.
> 
> This is why the component selector now takes literally five seconds to
> appear on Windows.
> 
> I have a patch in progress that adds parallels to these API functions
> that directly populate a list of LIB_ALIASes rather than their names.
> I'm in the process of testing it on all three platforms. It is a fairly
> minor addition, but I don't want to touch SCH_PLUGIN without permission
> since Wayne is working on it.
> 
> Wayne, are you okay with a patch that adds SCH_LEGACY_PLUGIN::
> EnumerateSymbolLib( std::vector<LIB_ALIAS*>&, ... )? This is the only
> place it touches the plugin API, plus a couple places in PART_LIB and
> several in the component chooser.
> 

If it temporarily resolves this issue, then I'm OK with it.  It would be
nice to be able to limit the exposure of this plugin call for just the
current PART_LIBS implementation which will have to remain forever to
support legacy symbol lookup.  Once symbol lookup by path goes away with
the symbol library table (in progress), this will not be necessary since
there will always be a one to one mapping of the symbol to a given
library.  In other words there will be no symbol lookup.  All symbol
access will be done by a full qualified LIB_ID.