Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
netikras26347223dAawwww :) it IS cute!
JKyll6416223dimagine how efficient most software would be today if we kept worrying about that stuff to that degree. One can dream.
N00bPancakes8293223dI used to work with some super smart ASIC engineers. Really great guys.
But I'm 90% sure that some of them didn't know what their chips 'did' in reality in... IRL.
Like I'm pretty sure they didn't know that when they picked up their smartphone and fumbled around with it ... they had no clue that their chips were handling that network traffic...
With just some tiny little bit of optimizing or forethought, software could be so much faster and more efficient.
In our Rails project at work, we have thousands of “resources” — basically named fancy nested macros. The lists of resource names are stored in string arrays, and they’re referenced by string everywhere. Using symbols instead would reduce the memory size by about 32%, and increase lookup speed by about 63%. (Just benchmarked this)
(Symbols in Ruby are immutable strings stored as ints under the hood, so they’re considerably faster)
It’s such a small change for such a large benefit, but even still, that’s a line-by-line optimization. Now better architectural patterns? That can go from 0.3x speed ups to 10x, 20x, etc.
If devs don’t give much thought to what their code is doing and why, it will always end up slow and voracious.
SortOfTested24504223dA month? What are these, logs for ants?
@Lensflare They work a little differently, but that’s a really good parallel.
Think of a global enum list where new enums are initialized upon first use. They’re just an int under the hood, so instantiation is quick, and doing lookups is also quick. They are unloaded eventually (in Ruby 2.2+) so there’s no runaway memory issue for dynamically created symbols.
Compare this to using strings for everything. Wasted memory, slower (and repeated) instantiations, slower lookups, uglier syntax colors 😅, ...
Ruby’s memory management is a little more complicated than this implies (and quite interesting), but the takeaway is that symbols are absolutely faster.
Not happening in ruby land but where I am just saw something similar-ish. Some queries were checking a perfectly good string as part of just what they do but were running slower.
Someone was all "hey what if that wasn't just a string" and checked something that was not a string, but effectivly indicated the same thing.
Speed increased dramatically.
Just one of those things nobody thought of at the start.
@Lensflare How Ruby handles memory is kind of interesting.
Instead of typing up a long description of allocating heap pages and object blocks, etc. on my phone, have a link!
There’s also some interestingness around symbols vs short vs long strings, arbitrary length integers, etc., but you’ll have to look through the mailing list for history on those (or look for other articles, I suppose!)