That's bootleg gzip.
this post was submitted on 06 Sep 2025
467 points (97.2% liked)
Programmer Humor
26332 readers
916 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Did you ever saw a char and thought: "Damn, 1 byte for a single char is pretty darn inefficient"? No? Well I did. So what I decided to do instead is to pack 5 chars, convert each char to a 2 digit integer and then concat those 5 2 digit ints together into one big unsigned int and boom, I saved 5 chars using only 4 instead of 5 bytes. The reason this works is, because one unsigned int is a ten digit long number and so I can save one char using 2 digits. In theory you could save 32 different chars using this technique (the first two digits of an unsigned int are 42 and if you dont want to account for a possible 0 in the beginning you end up with 32 chars). If you would decide to use all 10 digits you could save exactly 3 chars. Why should anyone do that? Idk. Is it way to much work to be useful? Yes. Was it funny? Yes.
Anyone whos interested in the code: Heres how I did it in C: https://pastebin.com/hDeHijX6
Yes I know, the code is probably bad, but I do not care. It was just a funny useless idea I had.
Mostly because compilers do this kind of stuff if you optimize for space, iirc. Not that you should never do it or something, but it kinda looks like premature optimization to me.
load more comments
(2 replies)
And here I was wasting time with bit fields to make my bools smaller.
My colleague said he didn’t see the point in storing enums as shorts or bytes instead of a full word, so I retaliated by storing them in their string form instead, arguing that it’ll be compressed by the db engine.
I'm a simple man. Here's my list of variable names:
Var1
Var2
Var3
Var4
Var5
...
At first I thought, "How are they going to compress 256 values, i.e. 1 Byte sized data, by "rearranging into integers"?
Then I saw your code and realized you are discarding 228 of them, effectively reducing the available symbol set by about 89%.
Speaking of efficiency: Since chars are essentially unsigned integers of size 1 byte and 'a' to 'z' are values 97 to 122 (decimal, both including) you can greatly simplify your turn_char_to_int method by just substracting 87 from each symbol to get them into your desired value range instead of using this cumbersome switch-case structure. Space (32) and dot (46) would still need special handling though to fit your desired range.
Bit-encoding your chosen 28 values directly would require 5 bit.
Use strings for everything and use a single universal method to convert some to floats only when you absolutely have to.
I have a coworker who does stuff like this and it's always low-benefit optimizations that cost the team time to interface with - but I do still kind of love it
load more comments
(5 replies)
Hey, this is awesome for saving space when writing things to NFC tags! Every bit still matters with those suckers
in the same vein (storing more data in less bits) you should check out tagged pointers as well!
I don't think that's a useless implementation at all. code looks relatively clean, and it definitely has its uses in the embedded systems world.
It is neither useless nor funny. It's optimization for storage capacity. If everyone in the world put in that level of effort into compression, computer storage and processing would actually be faster than the previous generation.
Processing would be quicker?
This would add significant processing overhead because of conversions everwhere. There is a lot of string processing going on inside your CPU already, I'm reasonably sure this would add a measurable overhead.
Plus I believe this would cause even more string related security vulnerabilities to emerge because of additional code that needs to be maintained.
This will actually run much slower. It saves space, but it has to do a bunch of math every time it needs to store or load a string I stead of just outputting it. Maybe if you had really limited cache space this could run faster (since it could save on fetching from RAM/storage), but, unless you're storing some really long strings, it won't make a difference.
load more comments
(3 replies)
now use the intchar to store prefixes for a smart string , or pack them to make a simd optimized b tree with 40 string prefixes per node instead of 32