# Dynamically generate a symbol name **URL:** \ **Category:** ruby-talk\ **Created:** [11 December 2007 11:51 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916 "2007-12-11T11:51:57Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Max\_Williams](https://avatars.discourse-cdn.com/v4/letter/m/278dde/32.png) [@Max\_Williams](https://rubytalk.org/u/Max_Williams)\ **Post date:** [11 December 2007 11:51 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/1 "2007-12-11T11:51:57Z")
I'm sure this is simple but i can't work out the syntax - if i want to use a bunch of symbols that are named :object0, :object2 ... :object9, how can i do something like 10.times do |n|   do\_something\_with(:object#{n} =\> "foo") end ie, do the same thing with but pass through a differently named symbol each time? thanks max > **路路路** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Sam\_Smoot](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@Sam\_Smoot](https://rubytalk.org/u/Sam_Smoot)\ **Post date:** [11 December 2007 12:00 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/2 "2007-12-11T12:00:03Z")
:"object#{n}" is the syntax. Or just "object#{n}".to\_sym. I would avoid doing this though. Symbols aren't meant to represent infinite variations. They're stored in a Hash internally, so the more symbols you add, the slower they get. So a small finite set of symbols is good. To represent environments, or database names, or even columns. Representing filenames as symbols, or user\_ids, or something similarly large and near as infinite as makes no difference is a bad idea IMO. At least if I understand the mechanics of Symbol storage. And I may not. 馃槈 > **路路路** > > On Dec 11, 5:51 am, Max Williams \ wrote: > > > I'm sure this is simple but i can't work out the syntax - if i want to > > use a bunch of symbols that are named :object0, :object2 ... :object9, > > how can i do something like > > > > 10.times do |n| > >   do\_something\_with(:object#{n} =\> "foo") > > end > > > > ie, do the same thing with but pass through a differently named symbol > > each time? > > > > thanks > > max > > -- > > Posted viahttp://www.ruby-forum.com/. ---
**Author:** ![7rans](https://avatars.discourse-cdn.com/v4/letter/7/a8b319/32.png) [@7rans](https://rubytalk.org/u/7rans)\ **Post date:** [11 December 2007 12:00 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/3 "2007-12-11T12:00:52Z")
10.times do |n|    do\_something\_with(:"object#{n}" =\> "foo") end T. > **路路路** > > On Dec 11, 6:51 am, Max Williams \ wrote: > > > I'm sure this is simple but i can't work out the syntax - if i want to > > use a bunch of symbols that are named :object0, :object2 ... :object9, > > how can i do something like > > > > 10.times do |n| > >   do\_something\_with(:object#{n} =\> "foo") > > end ---
**Author:** ![Gary\_Wright](https://avatars.discourse-cdn.com/v4/letter/g/58956e/32.png) [@Gary\_Wright](https://rubytalk.org/u/Gary_Wright)\ **Post date:** [11 December 2007 15:45 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/4 "2007-12-11T15:45:43Z")
Hash table performance shouldn't be affected by size, that is the whole point of using a hash table. The memory footprint will grow as you add symbols and since symbols are not garbage collected in MRI you might end up with a memory leak if you are constantly generating new symbols. Gary Wright > **路路路** > > On Dec 11, 2007, at 7:00 AM, Sam Smoot wrote: > > > :"object#{n}" is the syntax. Or just "object#{n}".to\_sym. > > > > I would avoid doing this though. Symbols aren't meant to represent > > infinite variations. They're stored in a Hash internally, so the more > > symbols you add, the slower they get. ---
**Author:** ![Sam\_Smoot](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@Sam\_Smoot](https://rubytalk.org/u/Sam_Smoot)\ **Post date:** [11 December 2007 17:49 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/5 "2007-12-11T17:49:59Z")
Ahh, thanks Gary. Guess that's my lack of a CompSci degree showing through. 馃槈 > **路路路** > > On Dec 11, 9:45 am, Gary Wright \ wrote: > > > On Dec 11, 2007, at 7:00 AM, Sam Smoot wrote: > > > > \> :"object#{n}" is the syntax. Or just "object#{n}".to\_sym. > > > > \> I would avoid doing this though. Symbols aren't meant to represent > > \> infinite variations. They're stored in a Hash internally, so the more > > \> symbols you add, the slower they get. > > > > Hash table performance shouldn't be affected by size, that is the > > whole point of using a hash table. > > > > The memory footprint will grow as you add symbols and > > since symbols are not garbage collected in MRI you might > > end up with a memory leak if you are constantly generating > > new symbols. > > > > Gary Wright ---
**Author:** ![Clifford\_Heath5](https://avatars.discourse-cdn.com/v4/letter/c/7ab992/32.png) [@Clifford\_Heath5](https://rubytalk.org/u/Clifford_Heath5)\ **Post date:** [11 December 2007 22:01 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/6 "2007-12-11T22:01:23Z")
Gary Wright wrote: > Hash table performance shouldn't be affected by size, that is the > whole point of using a hash table. Besides which any literal symbol references will probably be substituted by a pointer to the hash-table element at compile time. The hash table should only be used at compile time to provide a unique memory address. Obviously not in the case of :"...#{}" symbols though. Clifford Heath. ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [12 December 2007 07:29 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/7 "2007-12-12T07:29:52Z")
The memory footprint will increase. Unless you're already past the limit where each cache line on average only contains one accessed symbol, this memory footprint increase will decrease cache locality which again will decrease performance. In the general case: Depending on hash table implementation, you could also have chaining costs as your hash table grows to be full (which gives conflicts that need either chaining, a tree, or a rebuild of the table to handle). "Hash table performance is not affected by size" is a simplification that hold when you have a pre-90s microprocessor or a microcontroller and the entire hash table is in memory to start with and you have no two entries that hash to the same slot. This is a restricted case. Assuming some speed loss for increased size is a good assumption. As for the point of a hash table, I tend to think of it as "Fast access to data where the ordering property don't matter" (or lookup is convenient on something that isn't a number). Eivind. > **路路路** > > On Dec 11, 2007 4:45 PM, Gary Wright \ wrote: > > > On Dec 11, 2007, at 7:00 AM, Sam Smoot wrote: > > \> > > \> :"object#{n}" is the syntax. Or just "object#{n}".to\_sym. > > \> > > \> I would avoid doing this though. Symbols aren't meant to represent > > \> infinite variations. They're stored in a Hash internally, so the more > > \> symbols you add, the slower they get. > > > > Hash table performance shouldn't be affected by size, that is the > > whole point of using a hash table. ---
**Author:** ![Max\_Williams](https://avatars.discourse-cdn.com/v4/letter/m/278dde/32.png) [@Max\_Williams](https://rubytalk.org/u/Max_Williams)\ **Post date:** [12 December 2007 20:52 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/8 "2007-12-12T20:52:11Z")
cool, thanks guys. > **路路路** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Gary\_Wright](https://avatars.discourse-cdn.com/v4/letter/g/58956e/32.png) [@Gary\_Wright](https://rubytalk.org/u/Gary_Wright)\ **Post date:** [12 December 2007 08:40 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/9 "2007-12-12T08:40:44Z")
> The memory footprint will increase. Yes. I said that. > "Hash table performance is not affected by size" is a simplification > that hold when you have a pre-90s microprocessor or a microcontroller > and the entire hash table is in memory to start with and you have no > two entries that hash to the same slot. This is a restricted case. > Assuming some speed loss for increased size is a good assumption. Of course. But your observations are true of any data structure that indexes arbitrary data and so isn't all that helpful in understanding what differentiates a Hash with O(1) lookup from a Tree with O(log n) lookup from an Array with O(n) lookup. Gary Wright > **路路路** > > On Dec 12, 2007, at 2:29 AM, Eivind Eklund wrote: ---
**Author:** ![Eivind\_Eklund](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@Eivind\_Eklund](https://rubytalk.org/u/Eivind_Eklund)\ **Post date:** [12 December 2007 11:27 UTC](https://rubytalk.org/t/dynamically-generate-a-symbol-name/42916/10 "2007-12-12T11:27:29Z")
> \> The memory footprint will increase. > > Yes. I said that. And I repeated it with information about what that memory size increase meant, because I saw it as in conflict with what the rest of your text communicated, especially for those that don't know this stuff well. More details below. > \> "Hash table performance is not affected by size" is a simplification > \> that hold when you have a pre-90s microprocessor or a microcontroller > \> and the entire hash table is in memory to start with and you have no > \> two entries that hash to the same slot. This is a restricted case. > \> Assuming some speed loss for increased size is a good assumption. > > Of course. But your observations are true of any data structure that > indexes arbitrary data and so isn't all that helpful in understanding > what differentiates a Hash with O(1) lookup from a Tree with O(log n) > lookup from an Array with O(n) lookup. Absolutely agreed; my point was intended to be helpful in understanding how real world implementations work, as I understood it as if we were discussing a real world implementation (in particular, how the Ruby interpreter works). The abstractions are also useful; it's just that they are not the whole world, and it is easy to miss how the underlying details can make the conclusion invalid because the abstraction breaks. In particular, most analysis abstracts memory as if memory had constant access time. Nowadays, that abstraction breaks a lot. An anecdotal comparison to put it in perspective: Today, main memory has a speed compared to the CPU that's slower than the tape drive on a VAX compared to the CPU of the VAX. Another way to get some perspective: Today, a CPU generally executes several instructions per clock cycle. Ten years ago (last time I worked on doing cycle-by-cycle optimization outside embedded systems), a main memory fetch ran about 70 cycles. I couldn't find any numbers for today - but CPU speed increase at a rate of over 1.5x per year, while RAM speed increase at about 1.2x per year. Very conservatively, a cache miss take the same time as executing 150 non-cache-missing pipelined instructions. At large scales, you'll miss the cache anyway or not get incidental caching, so looking at the O-time of the algorithm is sort of sufficient. At very small scales, you'll always hit the cache, so the O-time is sufficient. At the intermediate scale - and I would guess Ruby symbol table lookups often would fit in there - you get very important cache interaction effects, including effects from whether cache lines incidentally grab more than one item. This means that the "hash lookup time is O(1)" claim does not hold for that case. This was my point. I hope the longer and more elaborate variant help somebody understand something they otherwise wouldn't. Eivind. > **路路路** > > On Dec 12, 2007 9:40 AM, Gary Wright \ wrote: > > > On Dec 12, 2007, at 2:29 AM, Eivind Eklund wrote: