3 ms·
I just read the article so it sounds like the author is punting on symbols in the direction of the video. Before responding now I went back and watched the vid
by bigtunacan 12y ago
I just read the article so it sounds like the author is punting on symbols in the direction of the video. Before responding now I went back and watched the video.
As far as the difference between "string".freeze and :string; the symbol will resolve to the same object_id every time across systems and processes. If you spin up irb and type :foo.object_id you will see 1092508. Now one way this is commonly used in Ruby is when we use Object#send. We pass a symbol in place of the function name as the first argument and internally this is used as a system optimization to lookup the function that is being called dynamically.
Now I haven't been knee deep in the code of any of the Rack web servers, but I would imagine that something like Puma which is built for concurrency and multi-threading could take advantage of this behavior as well for some shared process to enable spinning up lighter weight additional processes or threads thus leading to lower memory consumption on your web server and the ability to handle more traffic on the same hardware.
Erik is right in saying that strings and symbols are "converging"; they have not yet converged however. At the point at which strings converge to symbols in the sense that both resolve to the same object across systems, then what we have left is symbols and so it is not symbols that have been killed, but rather strings supplanted by symbols. If instead we go the direction of saying memory and performance don't matter so let's punt on that whole symbols are immutable thing I think we are giving up too much.
I use Ruby because the high level abstraction is great and saves me developer cycles, but I also want it to eek out as much performance as possible. Honestly in general I'm tired of hearing the argument that X should die now because it is a performance hack. Some performance hacks are good.
(For reference: In the video he discusses symbols vs freezing strings from 22:00 to 25:07)
- djur 12y ago> the symbol will resolve to the same object_id every time across systems and processes. If you spin up irb and type :foo.object_id you will see 1092508. object_id for symbols is not consistent across processes. % ruby -e "p :foo.object_id" 396968 % ruby -e "p :bar.object_id" 396968 % ruby -e ":bar; p :foo.object_id" 397128 You're getting 1092508 consistently not because it's :foo but because it's the next object_id available for a symbol after all the ones created during IRB startup.
- bigtunacan 12y agoWell dang... that is interesting and not what I expected. So from this I can infer that it also changes if a symbol is garbage collected now. So has the implementation of Object.send changed in Ruby 2.2+ as well? The latest copy of the code I have looked at is 1.9.3.
- djur 12y agoYes, symbols that are garbage collected will get new object IDs if they appear again. https://gist.github.com/mboeh/83338a4e3a6a77689e22 https://gist.github.com/mboeh/83338a4e3a6a77689e22