For a ~75KB emb file I'm seeing a ~7.5MB header generated. An example for the pw_bluetooth project:
Definition File
Size (KB)
Header Size (KB)
hci_events.emb
76
7488
hci_commands.emb
108
7376
hci_vendor.emb
32
2328
hci_common.emb
32
824
hci_data.emb
4
204
l2cap_frames.emb
4
60
hci_h4.emb
4
8
The scaling of input size to output size isn't consistent, so the behavior is definitely content driven.
Impact
Overhead of the backend generation step: larger headers take longer to generate
Slower compilation times: large headers result in long compile times even if a majority of the header is unreferenced
Hard to navigate: consumers of the headers have a lot of code to look at
Code analysis tools like clangd slow to a crawl when encountering the generated headers
Possible Improvements
C++ fragment templates include comments relevant to the emboss C++ backend, but not the generated code itself. We could trim out the comments when generating the code
Large amount of text conversion code (ostream, enum strings, etc). For many projects this is unnecessary, we should make it optional and/or split out to a separate header.
Large amount of code generated to wrap / validate / extract constant values, we can just use the constants directly.
I have a few patches pending that'll address 1 and 2. Just need to hold off until #130 lands since it has a significant changes to the code templates. FYI @robrussell
Issue
For a ~75KB
emb
file I'm seeing a ~7.5MB header generated. An example for thepw_bluetooth
project:The scaling of input size to output size isn't consistent, so the behavior is definitely content driven.
Impact
clangd
slow to a crawl when encountering the generated headersPossible Improvements