GMS 2023.4 - hashe struktur
Sobota, 15 Kwietnia 2023, 15:06
Czas czytania 2 minuty, 3 sekundy
Zgodne z GM:
Do czego służą funkcja variable_get_hash() ?
W GameMakerze co prawda istnieje zasada, że nazwy zmiennych mogą zawierać jedynie znak podkreślenia, łacińskie litery i cyfry (i nie mogą się zaczynać od cyfry), ale struktury pozwalają na używanie dowolnych nazw (włącznie ze spacjami i znakami diakrytycznymi) za pomocą funkcji:
kodvariable_struct_set(struct, name, value);oraz jej skróconego akcesora:
Żeby jednak to obsłużyć, pod maską GM używa hashy do przetrzymywania takich wartości, dzięki czemu jest to szybsze i odchodzi problem nietypowych liter w różnych językach.
Wskazówka:
Od wersji 2023.4 wprowadzono dodatkowe aliasy funkcji
Niestety, używanie
Dlatego w wersji 2023.4+ postanowiono udostępnić możliwość zapamiętania wyliczonego hasha i w ten sposób odczytywania wartości zmiennych w strukturze.
kodhash = variable_get_hash("klucz")
W ten sposób otrzymujemy na stałe hasha do zmiennych nazwanych "klucz" w dowolnej strukturze (wszystkie struktury hashują swoje nazwy tak samo).
Potem wystarczy już tylko odczytać zmienną "a" w strukturze za pomocą tej składni:
kodval = struct_get_from_hash(struct, hash);
Chociaż taki zapis od strony programisty nie jest szybszy, to jest on wolniejszy od struct.klucz raptem o max 1.15x.
Wskazówka:
Jeśli pobieramy jakąś wartość w evencie step 1 raz i wcześniej liczymy hash w tym samym evencie, nie uzyskamy żadnego zysku z tej konstrukcji. Aby uzyskać różnicę, dany hash musi albo nie być wyliczany co każdy step, albo użyty przynajmniej dwa razy w jednym stepie. Oznacza to, że najlepszy zysk dostaniemy, gdy hash wyliczymy w evencie Create, a potem używamy go np. w pętli, gdzie operujemy na tablicy struktur, lub na jakiejś zagłębionej strukturze..
Hashowanie ma zatem największy sens w przypadku dużych struktur danych, gdy mamy jakieś dynamiczne klucze, lub koniecznie chcemy używać nazw które nie są dozwolone jako zmienne w GML (np. aby generować JSON) - zapis struct.variable zawsze będzie najszybszy.
kodvariable_struct_set(struct, name, value);oraz jej skróconego akcesora:
struct[$ name] = value;Żeby jednak to obsłużyć, pod maską GM używa hashy do przetrzymywania takich wartości, dzięki czemu jest to szybsze i odchodzi problem nietypowych liter w różnych językach.
Wskazówka:
Od wersji 2023.4 wprowadzono dodatkowe aliasy funkcji
variable_struct_set, variable_struct_get, variable_struct_get_names, variable_struct_names_count, variable_struct_remove, variable_struct_exists, zabierając słowo "variable_". Możemy więc zamiennie używać struct_exists, struct_get, struct_set, struct_get_names, struct_names_count, struct_removeNiestety, używanie
struct[$ "klucz"] zamiast struct.klucz jest ok. 3x wolniejsze, gdyż za każdym razem wyliczany jest odpowiedni hash.Dlatego w wersji 2023.4+ postanowiono udostępnić możliwość zapamiętania wyliczonego hasha i w ten sposób odczytywania wartości zmiennych w strukturze.
kodhash = variable_get_hash("klucz")
W ten sposób otrzymujemy na stałe hasha do zmiennych nazwanych "klucz" w dowolnej strukturze (wszystkie struktury hashują swoje nazwy tak samo).
Potem wystarczy już tylko odczytać zmienną "a" w strukturze za pomocą tej składni:
kodval = struct_get_from_hash(struct, hash);
Chociaż taki zapis od strony programisty nie jest szybszy, to jest on wolniejszy od struct.klucz raptem o max 1.15x.
Wskazówka:
Jeśli pobieramy jakąś wartość w evencie step 1 raz i wcześniej liczymy hash w tym samym evencie, nie uzyskamy żadnego zysku z tej konstrukcji. Aby uzyskać różnicę, dany hash musi albo nie być wyliczany co każdy step, albo użyty przynajmniej dwa razy w jednym stepie. Oznacza to, że najlepszy zysk dostaniemy, gdy hash wyliczymy w evencie Create, a potem używamy go np. w pętli, gdzie operujemy na tablicy struktur, lub na jakiejś zagłębionej strukturze..
Hashowanie ma zatem największy sens w przypadku dużych struktur danych, gdy mamy jakieś dynamiczne klucze, lub koniecznie chcemy używać nazw które nie są dozwolone jako zmienne w GML (np. aby generować JSON) - zapis struct.variable zawsze będzie najszybszy.
