Po co używać symboli jako kluczy hashowych w Ruby?

Powodem jest wydajność, z wieloma zyskami nad ciągiem:

1. symbole są niezmienne, więc pytanie "co się stanie, jeśli klucz się zmieni?"nie trzeba pytać.
2. ciągi znaków są powielane w kodzie i zazwyczaj zajmują więcej miejsca w pamięci.
3. szukanie skrótu musi obliczać hash kluczy, aby je porównać. Jest to O(n) dla ciągów i stała dla symboli.

Ponadto Ruby 1.9 wprowadził uproszczoną składnię tylko dla hasha z klucze symboli (np. h.merge(foo: 42, bar: 6)), A Ruby 2.0 ma argumenty słów kluczowych , które działają tylko dla kluczy symboli.

uwagi:

1) Możesz być zaskoczony, gdy dowiesz się, że Ruby traktuje klucze String inaczej niż jakikolwiek inny typ. Rzeczywiście:

s = "foo"
h = {}
h[s] = "bar"
s.upcase!
h.rehash   # must be called whenever a key changes!
h[s]   # => nil, not "bar"
h.keys
h.keys.first.upcase!  # => TypeError: can't modify frozen string

Tylko dla kluczy łańcuchowych, Ruby użyje zamrożonej kopii zamiast samego obiektu.

2) litery "b"," a "i" r " są przechowywane tylko raz dla wszystkich wystąpień :bar w programie. Przed Rubim 2.2, to był zły pomysł, aby stale twórz nowe Symbols, które nigdy nie zostały ponownie użyte, ponieważ pozostaną w globalnej tabeli wyszukiwania symboli na zawsze. Ruby 2.2 będzie je zbierać, więc nie martw się.

3) w Rubim 1.8 obliczanie hasha dla symbolu nie zajęło dużo czasu.x, ponieważ ID obiektu zostało użyte bezpośrednio:

:bar.object_id == :bar.hash # => true in Ruby 1.8.7

W Ruby 1.9.x, zmieniło się to wraz ze zmianą hashów z jednej sesji na drugą (w tym z Symbols):

:bar.hash # => some number that will be different next time Ruby 1.9 is ran

[0] re: jaka jest przewaga nad używaniem Sznurka?

• Stylizacja: its the Ruby-way

• (bardzo) nieco szybsze szukanie wartości, ponieważ haszowanie symbolu jest równoznaczne z haszowaniem liczby całkowitej vs haszowaniem ciągu znaków.

• Wada: zużywa slot w tabeli symboli programu, który nigdy nie jest zwolniony.

Byłbym bardzo zainteresowany kontynuacją dotyczącą frozen strings wprowadzoną w Ruby 2.x.

Kiedy masz do czynienia z wieloma ciągami pochodzącymi z wejścia tekstowego (myślę o PARAMACH HTTP lub payload, na przykład przez Rack), jest o wiele łatwiej używać ciągów wszędzie.

Kiedy masz do czynienia z dziesiątkami z nich, ale nigdy się nie zmieniają( jeśli są twoim biznesowym "słownictwem"), lubię myśleć, że zamrożenie ich może coś zmienić. Nie zrobiłem jeszcze żadnego benchmarka, ale chyba bądź blisko wydajności symboli.