Ruby: Symbol vs String

Ha valakit mélyebben érdekelne a különbség (elsőre nem teljesen egyértelmű hogy mikor érdemes szimbólumot használni):

http://stackoverflow.com/questions/11447537/using-ruby-symbols
http://www.robertsosinski.com/2009/01/11/the-difference-between-ruby-sy…
http://www.troubleshooters.com/codecorn/ruby/symbols.htm

( hrgy84 | 2013. 06. 17., h – 16:56 )

Pedig egyszeru: a szimbolumok egy VM-globalis poolbol jovo konstans stringek (nem egeszen, de ez a legkozelebbi definicio, amit egy nem-rubysnak el lehet mondani). Egy adott szimbolum mindig ugyanaz az objektum lesz, ennek ugyanaz az elonye, mint a hatranya: a GC nem ervenyesul rajuk, csak VM shutdownnal. Ezert nem erdemes tul sok szimbolumot hasznalni a futas folyaman. Kicsit tobbek, mint konstansok es kicsit kevesebbek, mint a stringek. Es van rajuk egy csomo megkotes is.
Ha jol tudom, maga a szimbolum pool mersekelten threadsafe az MRI-ben, Rubinius ebben is sokkal jobb. Kicsit ragyurhatnanak az 1.9 es C-API kompatibilitasra, es akkor bekerulhetne a mainstream disztrokba.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Szerintem a megfogalmazásod alapján épphogy nem igazán értené meg egy nem Ruby-s, hogy Ruby-ban ez pont hogy működik és milyen gyakorlati haszna van.

"Ezert nem erdemes tul sok szimbolumot hasznalni a futas folyaman"

Pont az ellenkezőjére bíztatnak a fenti linkeken - a stackoverflow-s hozzászólások között is vannak tömör lényegre törők. Tehát éppen mivel egyetlen integer tárolódik a szimbólumhoz a program futása során és ez megváltoztathatatlan, ezért ahol elég a szimbólum, ott nagy sebesség növekedés érhető el a gyors összehasonlítás és egyéb műveletek miatt (mivel ugye egyetlen integer-t kell hasonlítani - ahogy feljebb is írják). Hash kulcsokhoz is ezért ajánlják. Illetve memória spóroló, mert a string műveletek során többszöröződik a string hossz alapján a memória foglalás, míg szimbólumnál nem.

Assemblyben is mas opkodja van az egyenlosegvizsgalatnak, meg az osszehasonlitasnak, nem veletlenul. Hint: XOR es CMP. Az egyik egy bitenkénti kizáró vagy utasítás (ami a bitminta tényleges egyezését vizsgálja), a másik meg előjeles kivonás. Az előbbi nem használható másra, csak egyenlőségvizsgálatra, míg az utóbbi összehasonlítás, tudsz vele rendezni.

A XOR nem egyenlőség vizsgálat, csak arra használják mert gondolom gyors. A CMP feltételes biteket billent be, így az egyenlőség vizsgálat is a CMP lenne melyre a BEQ vagy adott architektúrán használatos elágazó parancs használható.

A XOR nem használható másra? Ilyet inkább ne írj le.

http://www.tricksonrails.com/2010/06/avoid-memory-leaks-in-ruby-rails-c…

A cikk elso fele semmi egyebrol nem szol, mint a szimbolumokrol. Nem veletlenul irtam le, amit leirtam, a szimbolumok orokeletu cuccok, nem jon ertuk a kukasauto, csak amikor a VM leall. Nem szabad nyaklo nelkul alkalmazni oket, nagyon-nagyon at kell gondolni, hogy mikor hasznalod oket. Olvastam valahol egy cikket, sajnos nem tudok mar idezni belole, ezert nem talalom meg a googleval, de egy srac egy rubys appot optimalizalt memoriara, 40-50%-os memoriacsokkenest ert el csak az altal, hogy kigyomlalta azokat a szimbolumatalakitasokat, amikre nem volt mulhatatlanul szukseg.

A hashek kulcsa az pont egy jo pelda a szimbolumokra, de nagyon sok a hibas felhasznalas is, sajnos.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A fenti hozzászólásoddal nem a tartalma, hanem a célja volt a gond. Megpróbáltad 1-2 mondatban frappánsan összefoglalni, amit nem igazán lehet, nem véletlen írják le sok oldalban összeszedetten és érthetően a linkeken úgy, hogy kezdőknek érthető legyen. Te magas lóról el akarod intézni egy legyintéssel, de nem látom értelemét.

Annak, aki mar latott programozasi nyelvet, meg mondjuk programozott mar, az konnyen megerti, amit irtam. A nagyon kezdok meg ugysem arra kivancsiak, hogy performance szempontbol melyik a jobb, hanem hogy a kapcsos zarojelet hogy kell irni, hogy ne proc legyen belole.

Ossze lehet foglalni par mondatban, csak tudas kell a mondat megertesehez :-)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A fenti lényege nem az, hogy "magától lesz szám", még jó hogy megelőlegezel ilyen triviális dolgot másoknak :) Hanem hogy miután már létezik, onnétól fogva többé már csak egy integert kell összehasonlítani (persze egy lookup után), nem pedig karakterenként a string-eket, amelyek memória foglaltsága folyamatosan nő.

Nem a Symbol ellen tuntetek, en is imadok szimbolumokat hasznalni hash kulcsoknak, ha tehetem, csak azt hasznalom. Csak probalom tudatositani, hogy barmennyire is imadjuk oket, mindig gondoljuk at a hasznukat - mert a konnyu hasznalatert memoriaval kell fizetni. Amiota kiderult, hogy egy egyszeru kis Rails app nem volt kepes felbootolni 600 mega memoria mellett hogy asseteket forditsak rajta, azota rohadt ovatos vagyok a memoriahasznalat teren.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.