Speed up compilation of all our WriteAttribute machinery. #11603
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pullapprove
bot
requested review from
andy31415,
anush-apple,
austinh0,
balducci-apple,
carol-apple,
chrisdecenzo,
chulspro,
Damian-Nordic,
electrocucaracha,
erjiaqing,
franck-apple,
hawk248,
holbrookt,
jelderton,
jepenven-silabs,
jmartinez-silabs,
kghost,
kpschoedel,
LuDuda,
mlepage-google,
msandstedt,
pan-apple,
sagar-apple,
saurabhst,
selissia and
tecimovic
pullapprove
bot
requested review from
vivien-apple,
wbschiller,
woody-apple,
yufengwangca and
yunhanw-google
|
PR #11603: Size comparison from 89898f8 to fbc6e3d Full report (9 builds for k32w, p6, qpg, telink)
|
It turns out that instantiating fairly heavy-weight templates hundreds of times is slow to compile. Instead of having an instantiation per attribute, switch to only instantiating the complex templates per _type_ of attribute, with thin per-attribute wrappers for auto-deriving the cluster id and attribute id. This shaves over a minute of wall-clock time off compiling chip-tool for me, and close to 2 minutes of total CPU time.
bzbarsky-apple
force-pushed
the
faster-write-compile
branch
from
fbc6e3d
to
edb6f1c
Compare
|
PR #11603: Size comparison from 89898f8 to edb6f1c Decreases (2 builds for linux)
Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
woody-apple
approved these changes
Nov 9, 2021
yunhanw-google
approved these changes
Nov 9, 2021
mrjerryjohns
approved these changes
Nov 9, 2021
|
@msandstedt @saurabhst @jepenven-silabs @jmartinez-silabs @Damian-Nordic Please take a look? |
jmartinez-silabs
approved these changes
Nov 9, 2021
PSONALl
pushed a commit
to PSONALl/connectedhomeip
that referenced
this pull request
Dec 3, 2021
…ip#11603) It turns out that instantiating fairly heavy-weight templates hundreds of times is slow to compile. Instead of having an instantiation per attribute, switch to only instantiating the complex templates per _type_ of attribute, with thin per-attribute wrappers for auto-deriving the cluster id and attribute id. This shaves over a minute of wall-clock time off compiling chip-tool for me, and close to 2 minutes of total CPU time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It turns out that instantiating fairly heavy-weight templates hundreds
of times is slow to compile.
Instead of having an instantiation per attribute, switch to only
instantiating the complex templates per type of attribute, with thin
per-attribute wrappers for auto-deriving the cluster id and attribute
id. This shaves over a minute of wall-clock time off compiling
chip-tool for me, and close to 2 minutes of total CPU time.
Problem
Slower compiles than we want.
Change overview
See above.
Testing
No behavior changes, did lots of measurement of compile times.