Czy nazwy zmiennych wpływają na wydajność stron internetowych?


10

Czy nazwy zmiennych wpływają na wydajność witryny? Wiem, że będzie to bardzo niska liczba, ale czy ktoś może podać powody, dla których nie wybrałbym długiej nazwy zmiennej pod względem wydajności?


2
Proszę wyjaśnić swoje pytanie - gdzie jest ta zmienna i w jakim języku jest napisana?
Luke Graham

16
Nigdy nie powinieneś NIGDY wybierać krótkich i nielogicznych nazw zmiennych, jeśli twoje rozumowanie jest (wątpliwe) wydajnością. Kod źródłowy jest dostępny dla innych osób, aby go przeczytać, a nie dla zadowolenia komputerów i ich mikroskopijnego wzrostu wydajności.
Michael JV,

używam PHP ..
Avinash,

2
... A ty masz xpertdeveloper.com?
Jim G.,

3
Cześć Avinash, czy możesz wyjaśnić w swoim pytaniu swoje uzasadnienie dla myślenia, że ​​tak może być?

Odpowiedzi:


17

czy ktoś może podać powody, dla których nie wybrał długiej nazwy zmiennej pod względem wydajności?

Michael udzielił odpowiedzi (tj. Nie), ale nazwy zmiennych wpływają na wydajność programisty . Jeśli sprowadzisz nowego programistę lub kogoś, kto nie zna kodu, to długie i / lub mylące nazwy zmiennych mogą rozpraszać i spowalniać proces rozumienia.

Ogólnie rzecz biorąc, chcesz używać krótkich opisowych nazw zmiennych, ponieważ są one łatwiejsze do odczytania. Wyobraź sobie, że musisz zignorować swój kod przez 10 lat, a następnie ponownie wszystko zrozumieć. Wolisz przeczytać „getInput” lub „getInputFromUserWhoInputsStringOrElseInformReaderOfError”? (przesada oczywiście: P)

Są jednak chwile, kiedy posiadanie nieco dłuższej nazwy może być korzystne. Na przykład getBirthdayInput () byłby o wiele bardziej opisowy niż getInput (). Chcesz uprościć do pewnego momentu, ale nadmierne uproszczenie może być również problematyczne.


6
lepiej jest czytać długie nazwy, jeśli znajdziesz „getInputFromUserWhoInputsStringOrElseInformReaderOfError”, nie musisz czytać dokumentacji, co to za funkcja, jeśli znajdziesz „getInput”, czego potrzebujesz. Po 10 latach dokumentacja będzie błędna, niekompletna lub zaginiona. getInputFromUserWhoInputsStringOrElseInformReaderOfError jest z pewnością zbyt długi, ale lepsze jest zrozumienie tego, co jest długie (i nie obchodzi mnie, że kobiety twierdzą, że rozmiar nie ma znaczenia).
Dainius

Nie zgadzam się w tej sprawie. Myślę, że po prostu czytając kod, byłoby dość łatwo zrozumieć, co robi getInput (), szczególnie jeśli wypisze „nieprawidłowe dane wejściowe” lub coś takiego zaraz potem. Zdecydowanie są chwile, w których dłuższa nazwa może być lepsza - edytuję ją!
BlackJack

ofc zależy to od kontekstu, ale z mojego doświadczenia wynika, że ​​dłuższa nazwa jest lepsza (ale nie tak długo, jak getInputFromUserWhoInputsStringOrElseInformReaderOfError). A kontekst jest naprawdę ważny, ponieważ file.read () jest szybszy niż file.readAllFileAsByteArray (). Ale jak powiedziałem zwykle dłuższa nazwa IMHO zawiera więcej informacji.
Dainius

1
Jeśli dokumentacja jest nieprawidłowa, niekompletna lub jej brakuje, baza kodów i tak jest skazana na niepowodzenie.
Christopher Mahan

2
To odpowiedź na pytanie, które nie zostało zadane.

16

Nie, nie będzie. Mówiąc ogólnie, po skompilowaniu kodu nazwy zmiennych są zastępowane przez adres pamięci, do której się odnoszą. Komputery nic nie wiedzą o nazwach zmiennych; chcą tylko wiedzieć, gdzie przechowywane są wartości.

Zmienne są symbolami, niczym więcej. Zastępują wartości szesnastkowe nazwami, dzięki czemu programiści mogą łatwiej zrozumieć, co robią. Tak więc nie będzie zwiększenia wydajności poprzez wybranie krótszych nazw zmiennych.

To powiedziawszy, możesz uzyskać niewielkie (a mówię mikroskopijne) ulepszenia w czasach kompilacji i pierwszej interpretacji JIT, ale to tylko dlatego, że parser zajmuje kilka cykli procesora mniej, aby odczytać nazwę zmiennej. Jest to jednorazowy koszt i jest statystycznie nieistotny, gdy martwisz się o wydajność.


11
Chociaż Twoja odpowiedź jest poprawna w przypadku programowania aplikacji, OP odnosi się do stron internetowych, dlatego istnieje szansa, że ​​używa on tłumaczonego języka. W takim przypadku kod musiałby zostać wczytany z pliku, a następnie zinterpretowany. W takim przypadku dłuższa nazwa zmiennej ładuje się i parsuje dłużej. Jednak wzrost wydajności będzie nieznaczny i zostanie w znacznym stopniu zrównoważony dodatkowym kłopotem dla programisty czytania i rozumienia kodu.
Gavin Coates,

1
@Gavin Dotyczy to również języków interpretowanych - „pierwsza interpretacja JIT”. Większość interpretowanych języków kompiluje się teraz podczas ich wykonywania zamiast wykonywania wiersza po wierszu, AFAIK.
Michael K,

1
Michael - aby skompilować, plik należy najpierw wczytać do pamięci. Ten proces potrwa dłużej w zależności od długości pliku. Dłuższe nazwy zmiennych = dłuższe pliki.
Gavin Coates,

Pytanie jest oznaczone jako PHP. PHP nie ma jeszcze JIT - będzie to nowa funkcja wersji 8.0 zaplanowanej na koniec tego roku. Kompiluje się do kodu bajtowego przed wykonaniem, a kod bajtowy jest zazwyczaj buforowany na serwerach WWW w celu użycia w wielu żądaniach.
bdsl

8

Jeśli nie używasz pamięci podręcznej kodu operacyjnego (znanej również jako „akceleratory PHP”), to rzeczywiście ma to wpływ. Ale wpływ ten jest tak mały, że można go pominąć. Jeśli użyjesz pamięci podręcznej kodu operacyjnego, nie będzie to miało wpływu.


1
a jeśli zależy ci na wydajności tak bardzo, że zastanawiasz się nad skróceniem nazw zmiennych w celu uzyskania kilku cykli, nieużywanie pamięci podręcznej kodu operacji byłoby przestępstwem ... i zaleca się przejście na skompilowany język, taki jak C.
SF.

Ale oczywiście ten wpływ jest kumulatywny, więc im większa aplikacja, tym większy wpływ, prawda?
n00dles

Zend Opcache jest dostarczany z PHP od kilku lat, więc każdy powinien go używać. Myślę, że ogólnie jest domyślnie włączony.
bdsl

3

Podczas gdy Michael ma rację w programowaniu aplikacji, twoje pytanie dotyczy programowania stron internetowych z PHP, który jest językiem interpretowanym. W takim przypadku kod musiałby zostać wczytany z pliku, a następnie zinterpretowany. W takim przypadku dłuższa nazwa zmiennej ładuje się i parsuje dłużej.

Osiągnięta przy tym wydajność będzie jednak niewielka i prawdopodobnie będzie w granicach ułamków milisekundy dla całego skryptu. Zawsze możesz wypróbować go za pomocą przykładowego skryptu i zastosować metodę pomiaru czasu, taką jak opisana na stronie http://www.developerfusion.com/code/2058/determine-execution-time-in-php/, ale prawdopodobnie nie będzie to możliwe zacznij mierzyć czas po wczytaniu pliku. Ponadto czas wykonywania między kolejnymi próbami będzie się różnić znacznie bardziej niż różnica między długością nazw zmiennych, więc będziesz musiał wykonać znaczną liczbę prób i wziąć średnią każdego z nich, zanim będziesz mógł uzyskać zdalnie znaczącą średnią.

Jak zauważa BlackJack, dłuższe nazwy mogą być znacznie trudniejsze do zrozumienia i wymagają dużo dodatkowego wysiłku, aby je napisać (i są znacznie bardziej podatne na literówki). Chociaż może wystąpić niewielki wzrost wydajności, nie usprawiedliwia to dodatkowego problemu stworzonego dla programisty. Jako takie preferowane są krótkie, zwięzłe i łatwe do zrozumienia nazwy zmiennych.

Krótko mówiąc, nie przejmuj się nazwą zmiennej długości, zamiast tego skoncentruj się na pisaniu czystego, znaczącego kodu.


1

Może :

Kod serwera jest zwykle kompilowany, a długość nazwy zmiennej nie wpłynie na niego z wymienionych powodów. Jeśli jednak nazwa zmiennej jest używana do budowania znaczników, różne operacje na łańcuchach znaków. Ponieważ odpowiedź HTTP (zawierająca znaczniki / zwrócone dane json / zwrócone dane) jest większa, potrwa to nieco dłużej, chociaż różnica będzie nieznaczna. Jeśli JavaScript nie zostanie zminimalizowany, będzie to większy plik, podróżowanie do klienta potrwa dłużej.

Oprócz minimalizacji plików JavaScript wszelkie wysiłki związane z optymalizacją aplikacji / strony internetowej będą lepiej przeznaczane na inne aspekty.


1

Tak, ale nie w tym sensie, o jakim myślisz.

Przy złych nazwach zmiennych programiści mogą łatwo pomylić się z kodem źródłowym. Będzie trudny do odczytania i trudny do zrozumienia.

Ostatecznie kod źródłowy będzie trudny do utrzymania i jego ewolucja będzie prawie niemożliwa. Doprowadzi to nieuchronnie do wyższych kosztów utrzymania, wyższych kosztów rozwoju, większej liczby błędów i gorszej wydajności .

Zmienna nazwa nie będzie miała absolutnie żadnego wpływu w czasie wykonywania i całkowicie pomijalna w czasie kompilacji. Ale złe nazwy nieuchronnie doprowadzą do złej wydajności, ponieważ nikt nie rozumie kodu i kończy się na stosie hakowania jeden na drugim, co pogarsza za każdym razem.

Przeczytaj je, aby dowiedzieć się o dobrej nazwie zmiennej: http://tottinge.blogsome.com/meaningfulnames

Zauważ, że jeśli odczuwasz potrzebę bardzo długiej nazwy zmiennej, oznacza to, że twój kod jest źle skonstruowany. Nazwa zmiennej jest zawsze wyrażana w kontekście: przestrzeń nazw, nazwa klasy, nazwa pliku, folder, nazwa funkcji itp. Zatem, jeśli nazwa musi być długa, aby była wyraźna, oznacza to, że rzecz, którą próbujesz nazwać DOESN ' T BELONG TUTAJ . W takim przypadku pomyśl o umieszczeniu tego kodu w odpowiednim miejscu lub utwórz to miejsce, jeśli jeszcze nie istnieje.


0

Odpowiedź brzmi oczywiście tak, jeśli chodzi o php.

Odpowiedzi, które mówią, że to nie zmieni, niekoniecznie są poprawne. Na przykład mam mały skrypt php, tylko kilka wierszy, ale musi on zapętlić około 1 950 000 razy, zanim skończy swoje zadanie, więc chociaż jedno uruchomienie skryptu może nie zostać zauważone, te ułamki sekundy sumują się znacznie, gdy zapętlając wiele razy.


1
Ale się mylisz. Każdy przyzwoity interpreter php parsuje kod tylko raz. Faceci piszący tłumacze PHP nie są głupi.
gnasher729

@ gnasher729 Zakładasz, jak działa interpreter lub cały serwer i nigdy nie powinieneś tego robić. Nawet jeśli będzie parsował tylko raz dla każdego uruchomienia, może ponownie analizować przy każdym uruchomieniu i nie buforować przeanalizowanej reprezentacji (inne systemy to zrobią, ale nie możesz wiedzieć z góry). Generalnie im więcej bajtów, tym dłuższy czas parsowania. Tak więc Diorthotis nie jest ogólnie zły, może mylić się tylko co do konkretnego systemu.
Mecki

0

Możesz używać krótkich nazw, które czynią kod mniej czytelnym. Zaoszczędzisz mikrosekundę lub dwie. Ponieważ kod jest mniej czytelny, trudniej jest go ulepszyć i przyspieszyć. Tak więc twój nieusuwalny, niemożliwy do poprawienia kod z krótkimi nazwami skończy w końcu znacznie wolniej.

Aby odpowiedzieć na pytanie („czy wpływa to na wydajność”): Tak, ale nie tak, jak lubisz.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.