| Thread Previous • Date Previous • Date Next • Thread Next |
In nightly, I would say the first opening is maybe a little faster, however for every other usage in session it takes like half a second. Could it be just an issue with the GUI (the progress bar causes the delay as it has to subsequently show all the names of libraries)? It is just my guess, I have no idea how the progress bar in wxWidgets works.
Jan Dne 28.12.2017 v 23:41 Wayne Stambaugh napsal(a):
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_______________________________________________ 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
| Thread Previous • Date Previous • Date Next • Thread Next |
