C++ backend generates excessively large headers
- Dominant language
- Python
- Stars
- 92
- Forks
- 30
- PR merge metrics
- No merged PRs in 30d
Description
### Issue
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
1. 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
2. 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.
3. Large amount of code generated to wrap / validate / extract constant values, we can just use the constants directly.
Contributor guide
Assessment
This issue has not been assessed yet.