That's bootleg gzip.
Programmer Humor
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
And here I was wasting time with bit fields to make my bools smaller.
I mean… you’d get better results for large data sets by just using a known compression algorithm. This is only viable for situations where you only have a small amount of data, enough computation to run this conditional, but not enough computation to run compression/decompression.
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.
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.
No, it doesn't. It can't know if you need a full set of characters or only a subset of them, so it can't optimize like this. If you know you only need to represent capital letters and a few punctuations, you can do something like the OP. The compiler has to assume you could need the full range of characters represented by the format though (especially since it doesn't even know if you'll continue to use them as characters—you may want to do arithmetic on them).
Definitely premature optimization, and not even ose to optimal either. It's next to useless, but I think the OP was just having fun.
Idk, I just had this funny idea, and thought I could do this as a cool and quick proof of example
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.
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
Use strings for everything and use a single universal method to convert some to floats only when you absolutely have to.
C lets you do this by putting text in single quotes:
int foo = 'Abcd';
works
Hey, this is awesome for saving space when writing things to NFC tags! Every bit still matters with those suckers
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
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.
Unless you only copy and compare you have to decode it, or implement more complicated logic for everything from searching to concatenation (which is normally just memcopy).
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.