kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #30308
Re: LIB_PART data storage refactor
-
To:
<kicad-developers@xxxxxxxxxxxxxxxxxxx>
-
From:
Maciej Suminski <maciej.suminski@xxxxxxx>
-
Date:
Mon, 14 Aug 2017 22:34:48 +0200
-
Authentication-results:
spf=pass (sender IP is 188.184.36.48) 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:
<02be1d87-c339-1dc4-f207-bf0266fcb24f@cern.ch>
-
Spamdiagnosticmetadata:
NSPM
-
Spamdiagnosticoutput:
1:99
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
On 08/14/2017 10:33 PM, Maciej Suminski wrote:
> 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
^ not
> 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
References
