kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #30307
Re: LIB_PART data storage refactor
-
To:
<kicad-developers@xxxxxxxxxxxxxxxxxxx>
-
From:
Maciej Suminski <maciej.suminski@xxxxxxx>
-
Date:
Mon, 14 Aug 2017 22:33:04 +0200
-
Authentication-results:
spf=pass (sender IP is 188.184.36.50) smtp.mailfrom=cern.ch; lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=bestguesspass action=none header.from=cern.ch;
-
In-reply-to:
<35d7c071-676e-e135-83e0-cbd85aaa6e24@gmail.com>
-
Spamdiagnosticmetadata:
NSPM
-
Spamdiagnosticoutput:
1:99
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
I measured the time spent in SCH_SCREEN::Draw() for the slowest to
render sheet I have found ("Northbridge" subsheet of the c4puter
project) and I could observe any performance drop. There was no
noticeable difference for designs of medium complexity either.
I believe the iteration overhead (additional condition checks when
moving between different LIB_ITEM types) might be the easiest to notice
for the smallest sheets, but then I wonder whether it matters if it
takes 1 ms or 1.5 ms to render.
Anyway, this is why I published the patch for testing. Perhaps the
change works wonders on my platform but slows down on other configurations.
Cheers,
Orson
On 08/14/2017 06:39 PM, Wayne Stambaugh wrote:
> 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
>>
>
> _______________________________________________
> 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