[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.
I think it depends on codegen around the access and storage for that enum. We have to pick a default though, so I think the default given by the compiler is pretty good unless we have a reason to think it would help us out to pack more tightly. It may come down to codegen for ints being tighter than codegen for bytes. We aren't making large arrays of enums where the space savings would matter too much. In structs, I think they'll be packed next to ints and other align-4 entitites anyway and so this won't make a difference in overall struct size.

Generated at Thu Feb 08 06:45:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.