kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #30306
Re: LIB_PART data storage refactor
This improves load performance which makes sense but what about the
performance hit when iterating over the list of all LIB_ITEMs say during
drawing which happens frequently? Would it make more sense to limit the
sorting until it's required instead of every change or file load? I'm
not opposed to this patch, but looking at it makes me wonder if this is
the best solution.
On 8/14/2017 11:21 AM, Maciej Suminski wrote:
> Hi,
>
> In the attachment you will find a patch that refactors data storage in
> LIB_PART. Instead of keeping all drawings in a
> boost::ptr_vector<LIB_ITEM>, the items are stored in an integer to
> LIB_ITEMS map. Thanks to that, it is no longer necessary to call
> LIB_ITEMS::sort() on every modification, so the result is ~33% library
> loading. I see some other places where the performance could be enhanced
> thanks to the refactor, so if this change works then I will try to
> improve other areas.
>
> I would appreciate a bit of help from brave testers that could take the
> patch for a test drive and confirm whether it satisfies expectations.
>
> Regards,
> Orson
>
>
>
> _______________________________________________
> 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
>
Follow ups
References