kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

You cannot fairly compare opening 20 or so symbol libraries compared to
90+ symbol libraries.  Try cutting your global symbol library table down
to 20-25 symbol libraries see if that improves the performance issues.
You could also create a project file (.pro) that has all of the symbol
libraries in the default symbol library table and compare the
performance with this many libraries using version 4.  I'm guessing you
will see a similar performance hit.

On 12/28/2017 05:36 PM, Jan Mrázek wrote:
> Chris and Wayne,
> 
> I have the latest nightly build and I can confirm a slow-down when I try
> to add a component in a schematic. The first usage after KiCAD startup
> takes roughly 3-5 seconds to load. Every other usage takes approx. 0.5
> seconds and it is quite annoying and productivity killing.
> 
> I was used to that in the stable KiCAD (4.0.7) the first library load
> takes a while, but after that the component chooser opens automatically.
> 
> Jan
> 
> 
> Dne 28.12.2017 v 23:29 Wayne Stambaugh napsal(a):
>> Chris,
>>
>> I stand corrected.  I just messed around a bit with this on Debian and
>> it works as I previously described.  The first load is slow because of
>> the caching of both the symbol libraries and the footprint libraries.
>> On the second launch of the chooser, the symbol library progress dialog
>> is dismissed almost immediately and the chooser dialog displays very
>> quickly.  This is with a debug build so it should only be faster with a
>> release build.  We really need to add a static flag to only show the
>> progress dialog the first time the symbols are loaded.  Do you know what
>> git commit users are noticing the performance issues?  It's possible
>> they could be using older nightly builds that still have the issue
>> Orson's changes caused.
>>
>> Wayne
>>
>> On 12/28/2017 04:58 PM, Chris Pavlina wrote:
>>> Thank you, Wayne. Let me know if there's anything you want me to look
>>> into or do - I've missed a lot of the new code and don't really have
>>> time to work out from scratch what went wrong, but I'll gladly help out
>>> with a point in the right direction. And let me know if you do you want
>>> me to put it behind an option. As much as I like this feature, it's more
>>> important to me that the chooser be quick and responsive.
>>>
>>> On Thu, Dec 28, 2017 at 09:56:50PM +0000, Wayne Stambaugh wrote:
>>>> I don't think it's the footprint preview that is the issue.  I think
>>>> something happened when the symbol library table progress dialog was
>>>> added or afterwards.  When I added the symbol library table code, it
>>>> was
>>>> slow the first time you opened the chooser because the symbol library
>>>> table uses lazy loading so all 90+ symbol libraries (assuming you are
>>>> using the default symbol library table) get loaded.  After the initial
>>>> load, it was very fast.  Something has changed since then and it
>>>> appears
>>>> the symbol library table is being reloaded every time the chooser is
>>>> launched.  Once I plow through my backlog of patches to test and merge,
>>>> I will take a look at it.
>>>>
>>>> Wayne
>>>>
>>>> On 12/28/2017 04:48 PM, Jeff Young wrote:
>>>>> Something definitely happened.  It was fast for me, but now takes
>>>>> several seconds.
>>>>>
>>>>> On the other hand, not having it would be worse.
>>>>>
>>>>> Cheers,
>>>>> Jeff.
>>>>>
>>>>>> On 28 Dec 2017, at 20:58, Chris Pavlina <pavlina.chris@xxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> How many have noticed a drop in performance in the component chooser,
>>>>>> particularly surrounding footprint preview? I've noticed a rise in
>>>>>> complaints about it, including one now who's saying it takes
>>>>>> around two
>>>>>> seconds to open every time. I'm not sure if something changed since I
>>>>>> wrote it or if I'm just getting more complaints as it gets tested
>>>>>> on a
>>>>>> wider range of systems.
>>>>>>
>>>>>> If the performance is poor, I may option out the footprint
>>>>>> preview/chooser before release so we don't release a turkey. I
>>>>>> definitely don't have time to actually _fix_ it before then. So...
>>>>>> what
>>>>>> are people seeing for performance here? It's still fast for me but
>>>>>> I'm
>>>>>> using it with a small library on a fast system.
>>>>>>
>>>>>> -- 
>>>>>> Chris
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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