“Turn All Your Enums Into Bytes Now!” | Code Cop
Vložit
- čas přidán 17. 03. 2024
- Use code KUBE20 and get 20% off the brand new "From Zero to Hero: Kubernetes for Developers" course on Dometrain: dometrain.com/course/from-zer...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this episode of Code Cop, I will talk about enums and how turning them into bytes instead of integers makes absolutely no sense.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
There is a compiler code analysis warning for this situation that, if enabled, will trigger if you set an enum to anything other than int.
So while this optimization is probably irrelevant for most applications, unless you have millions of rows in a database. I don't see the harm in it. And you do a terrible job of explaining it, all you do is to appeal to the authority of microsoft(And hey, they gave us Windows so maybe they are not perfectly efficient or they just didn't see it/ didn't care). Maybe tell us why it is bad enough to be called "irredeemable on every single level"
Actually, I had a couple of times specified a non-default base type for enums. But in all those cases the actual data was transferred as a binary stream via a serial connection to an embedded device, so I had to carefully follow the protocol.
Context indeed matters. I used a byte enum yesterday to reduce the packet size of a serial messaging protocol.
I swear with every Code Cop video Nick becomes more and more insane 😂
It is a micro optimization for most databases. But you can have tables with tens or hundreds millions of records where some of the columns are enum values. It can make indexes perform better by being smaller. This tip might not be very relevant to many applications but it is not wrong.
For one reason or another I had to write a parser/serializer for some obscure format (existing one could not handle memory requirements we had - would hog up ALL THE MEMORY on a machine).
For anyone wondering, you can actually harm performance doing this, or at least the CLR will likely align fields to 4 byte or 8 byte boundaries (by default) anyway to ensure performance is not harmed. So you might have an int field, then your 1-byte struct, then another int field. The CLR would likely use 32 bits for that 8 bit struct anyway, such that the layout would be 32 bit int, 8 bit struct with 24 wasted bits, then the final 32 bit int.
I used to work on a transactionnal database that was dealing primary keys, enums with bigints, bigints everywhere! I can tell you that optimizing storage can lead to significant performances as well lowering storage for back ups and data warehouses. As for enums, I always use default integers, but if we do have millions of millions of records, i may consider using other types depending on the range of values or reconsider using a different design approach (using discriminators or not i.e table per types etc). Storage cost are very low nowadays anyways.
Just to be clear, 100% with you :). There are times of course where you should think of the types in the db. A concrete example from my previous job where we went from storing guids in strings (BigQuery didn’t have a native format for guids at the time) to its byte representation saved us a lot of storage space, and since we ingested about 10TB of json every day that optimization actually saves us quite a lot of money.
We cast enums to bytes at our work, because the database is very old (25+ years), and we have some foreign keys to constant types, where the foreign key were of type [tiny] and now that we integrated EF core, we instead of making a join on the table that stores the value name, we just use enums of type [byte] - this just makes the EF to SQL relation easier.
To be honest I do it too, when I create an Enum to be saved in database I give byte type, because it just a keyword and conversion in dbcontext and nothing more, easy to implement. Yes most probably projects I worked on had missing better performance optimization but it does not matter, if I am aware of something while implementing, I will do it. It does not take a lot of effort.
There's nothing wrong with saving 3 bytes on a column in SQL Server. Odds are you have more problems than this, but that doesn't inherently make it a problem to seek out the savings. As far as how that should translate to the C# representations, I think there's room to debate.
I think most people struggle to understand that optimization or "savings" have a factor/scale to them, and you can look at how effective/valuable a certain optimization or trick is by examining how it's going to
When I was told about this video my instinctual answer was "with such cheap storage available, why waste your time" and my second reaction was "database normalisation is better than worrying about enum types". Maybe that reaction is 'cos I'm a database programmer at heart. Hear, hear on identifying what is a failure in understanding, not a tip.
Something I haven't seen mentioned is message structs. For one of my work projects we had a messaging system that was marshalling message structs and sending them over legacy hardware with very low bandwidth. In some structs, the fields were marshalled as int32 so when message frequency was high it would start slowing down. These fields were used in combination to represent some state. We found a way to optimize and drastically reduce the size by representing each state as a single byte under one enum and use bitwise operations to combine the states together using bit masking.
I've done this and I will probably do it again, but I'd never post it as a general advice, since it's much more likely to a headache while programming than it is to affect performance. For storing enums in a database, I'd use byte (tinyint) atleast 95/100 times though, since it'll be a primary key and I have some autistic traits.
In general, it's good advice to follow the conventions of whatever programming language or environment you're using, even if on the surface the convention may seem counter-intuitive. The convention for always using the `int` type in C# is a prime example. It may seem intuitive to use the smallest integer type to hold range of values needed, but the wisdom of the crowd knows something that isn't obvious, namely modern processors are optimized process data values on 32-bit and 64-bit boundaries. So you may think your being smart and efficient, but in reality there's no benefit.
The general advice is something along the lines of "Prefer what is natural, not what is the smallest." With enums, you have to remember that they are just named integers ‒ by default there are 4 millions other valid values in addition to the 10 you enumerate, but why bother getting rid of them? If there is a
This enum byte thing exists like 15 years.