[SERVER-81113] IDL should choose a more approriate default size for enum Created: 15/Sep/23 Updated: 07/Dec/23 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Mark Benvenuto | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | perf-tiger, perf-tiger-handoff, perf-tiger-non-q4, perf-tiger-triaged | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Sprint: | Service Arch Prioritized List |
| Participants: |
| Description |
|
Enums are 4 bytes by default in C++ on x64/arm64. Most IDL generated enums fit in 1 byte and show IDL should specify an appropriate size for all enums in the generated C++ code. |
| Comments |
| Comment by Mark Benvenuto [ 27/Oct/23 ] |
|
Not all IDL generated enums are embedded in IDL structs. Most enums are but the IDL generated enums also have been widely used (ActionType, ReadPreference are two such examples). While holes can still happen in structs, at least users can manually tune the packing by rearranging the fields. We could always change IDL to pack structs more efficiently in these narrow cases (this is unlikely to help many structs, my guess < 10). In lieu of this, we could add the ability for users to custom their enum size so in some cases, users can tune the generated enum size. IDL could even be validate their size can contain their values. Example: it would be erroneous to have 257 values in a 1 byte enum. We could use https://github.com/acmel/dwarves to find holes in structs |
| Comment by Billy Donahue [ 28/Sep/23 ] |
|
Even if all values of the enum fit into 1 byte, storing them a single bytes isn't necessarily an optimization. |