Well, no. They are not certainly using int, they might be using a more efficient data type.
This might be for legacy reasons or it might be intentional because it might actually matter a lot. If I make up an example, chat_participant_id is definitely stored with each message and probably also in some index, so you can search the messages. Multiply this over all chats on WhatsApp, even the ones with only two people in, and the difference between u8 and u16 might matter a lot.
But I understand how a TypeScript or Java dev could think that the difference between 1 and 4 bytes is negligible.
Probably why I said “almost certainly”. And I stand by that. We’re not talking about chat_participant_id, we’re talking about GROUP_CHAT_LIMIT, probably a constant somewhere. And we’re talking about a value that would require a 9-bit unsigned int to store it, at a minimum (and therefore at least a 16-bit integer in sizes that actually exist for types). Unless it’s 8-bit and interprets a 0 as 256, which is highly unorthodox and would require bespoke coding basically all over instead of a basic num <= GROUP_CHAT_LIMIT.
Orrrr they have a u8 chat_participant_id of some kind and a binary data format for message passing. The GROUP_CHAT_LIMIT const may have a bigger data type, but they may very well be trying to conserve 3 bytes per message. Ids can easily start at 0.
150 gigs of bandwidth saved per day doesn’t seem like a whole lot at their scale, but if they archive all the metadata, that’s over 50 terabytes a year saved on storage - multiplied by how many copies they have of their data. Still not a lot tbh, but if they also conserve data in every other place they can, they could be saving petabytes per year in storage.
Still weird because then they’d have to reuse ids when people leave, otherwise you could join and leave 255 times to disable a group lol
And we’re talking about a value that would require a 9-bit unsigned int to store it, at a minimum (and therefore at least a 16-bit integer in sizes that actually exist for types). Unless it’s 8-bit and interprets a 0 as 256, which is highly unorthodox and would require bespoke coding basically all over instead of a basic num <= GROUP_CHAT_LIMIT.
I think you’re just very confused friend, or misunderstanding how binary counting works, because why in the 9 hells would they be using 9 bits (512 possible values) to store 8 bits (256 possible members) of data?
I think you’re confusing indexing (0-255) with counting (0-256), and mistakenly including a negation state (counting 0, which would be a null state for the variable) in your conception of the process. Because yes, index 255 is in fact count 256 and 0 would actually be 1. Index = count -1
Well, no. They are not certainly using
int, they might be using a more efficient data type.This might be for legacy reasons or it might be intentional because it might actually matter a lot. If I make up an example,
chat_participant_idis definitely stored with each message and probably also in some index, so you can search the messages. Multiply this over all chats on WhatsApp, even the ones with only two people in, and the difference betweenu8andu16might matter a lot.But I understand how a TypeScript or Java dev could think that the difference between 1 and 4 bytes is negligible.
Shots fired.
All these tough guys think you can’t bit shift in Java, never worked on a project with more than two people. Many such cases.
Fair point, but still better than wasting a nuclear power plant worth of electricity to solve math homework with an LLM
Probably why I said “almost certainly”. And I stand by that. We’re not talking about
chat_participant_id, we’re talking aboutGROUP_CHAT_LIMIT, probably a constant somewhere. And we’re talking about a value that would require a 9-bit unsigned int to store it, at a minimum (and therefore at least a 16-bit integer in sizes that actually exist for types). Unless it’s 8-bit and interprets a 0 as 256, which is highly unorthodox and would require bespoke coding basically all over instead of a basicnum <= GROUP_CHAT_LIMIT.Orrrr they have a u8 chat_participant_id of some kind and a binary data format for message passing. The GROUP_CHAT_LIMIT const may have a bigger data type, but they may very well be trying to conserve 3 bytes per message. Ids can easily start at 0.
150 gigs of bandwidth saved per day doesn’t seem like a whole lot at their scale, but if they archive all the metadata, that’s over 50 terabytes a year saved on storage - multiplied by how many copies they have of their data. Still not a lot tbh, but if they also conserve data in every other place they can, they could be saving petabytes per year in storage.
Still weird because then they’d have to reuse ids when people leave, otherwise you could join and leave 255 times to disable a group lol
I think you’re just very confused friend, or misunderstanding how binary counting works, because why in the 9 hells would they be using 9 bits (512 possible values) to store 8 bits (256 possible members) of data?
I think you’re confusing indexing (0-255) with counting (0-256), and mistakenly including a negation state (counting 0, which would be a null state for the variable) in your conception of the process. Because yes, index 255 is in fact count 256 and 0 would actually be 1. Index = count -1
I’m imagining something like this:
def add_member(group, user): if (len(group.members) <= GROUP_CHAT_LIMIT): ...If
GROUP_CHAT_LIMITis 8 bits, this does not work.So add a +1 like you would for any index to count comparison?
I guess I’m failing to see how this doesn’t work as long as you properly handle the comparison logic. Maybe you can explain how this doesn’t work…