TomRiddle napisał(a):
Napisałem to w poście wyżej, bo korzysta z IO i z socketów.
Tu nie chodzi o microbenchmark, tylko o działanie aplikacji. Ile razy wywołujesz tę funkcję i jak? Z każdym żądaniem HTTP? Co sekundę? Na wątku w tle? Na wątku UI? To, że unikniesz kilku cykli procesora w tym miejscu nie oznacza, że trzymanie hashmapy ma jakikolwiek sens.
Idealnie by było gdyby nazwa była wymowna i nie musiałbyś szukać nigdzie indziej informacji o tym.
Jeżeli piszesz cache, to napisz go poprawnie i nazwij metodę isYadaYadaCached
. Jeżeli zaczniesz wymyślać coś innego, to tylko spowodujesz pytania.
Nie mierzyłem, ale mam mózg i wiem bez sprawdzania że implementacja oparta na mapie jest szybsza niż fetchowanie czegoś z IO/socket'ów.
Ponownie: GC? Czy to jest na wątku w tle? Czy na wątku UI? Czy to jest ścieżka krytyczna? Kto wypełnia słownik? Kto go czyści? Jak często?
Nie jest pomijalna.
O, to cenna informacja. To dlaczego nie jest pomijalna? Czy to jest ścieżka krytyczna? Co jeżeli ktoś za tydzień postanowi usunąć sprawdzanie w tej hashmapie, co się wywali?
Nie mogę pozbyć się całkowicie hash'mapy bo ten szybki pre-test nie jest jej jedynym zadaniem, jest istotnym elementem innej części aplikacji (głównie UI).
Czyli masz jakiś stan używany w innych miejscach aplikacji? Czy da się tego uniknąć? Czy da się te dwa słowniki rozdzielić? Ponownie: co jeżeli ktoś usunie sprawdzanie przy pomocy hashmapy, co się zepsuje?
Jeśli ktoś przebuduję część aplikacji, to faktycznie implementację fast/slow check'a trzeba będzie zmienić. Teraz to jest zupełnie nie potrzebne.
No i ponownie, skąd wiadomo, że trzeba będzie to zmienić? Jeżeli teraz masz jakieś argumenty na poparcie swojej implementacji, to dlaczego nie udokumentować ich?
Właśnie dokładnie dlatego chcę poświęcić czas i dobrze nazwać tę funkcję - żeby dokładnie mówiła czym jest i co robi.
Ponownie podtrzymuję swoją opinię, że nazwą nie przekażesz tego, co przekażesz dobrą dokumentacją.
A jakie to ma w ogóle znaczenie? Nawet gdyby to był 1%, to i tak warto zrobić pre-test, bo a nuż się okaże że pre-test dał
true
i wykonywanie ciężkiej operacji nie ma sensu.
Ma znaczenie, bo hashmapa zajmuje miejsce w pamięci, więc obciąża GC i serwer. Ponadto w słowniku mogą być niepoprawne dane i tym nieznaczącym kawałkiem kodu wprowadzisz buga.
"około" znaczy 70-90%. Mniej więcej 8/10 case'ów - widzę po reakcji programu że trochę krócej mieli.
Czy da się to zapisać jako test jednostkowy/wydajnościowy/jakikolwiek? Za tydzień ktoś będzie chciał to zmienić i nie będzie musiał myśleć, czy używanie dodatkowej ścieżki ma sens.
BO WYCIĄGANIE Z MAPY PO KLUCZU JEST JEDNĄ SZYBSZYCH OPERACJI W JAVIE. Szybsze chyba może być tylko dostęp do array'a po indexie.
Takie stwierdzenie jest bardzo ryzykowne, bo implementacji map jest mnóstwo, a nawet przy używaniu hashmap nie jest to oczywiste (chociażby kwestie wyliczania hasha dla stringa lub obiektu). No i znowu: co z GC?
No nie. Teraz to muszę pisać w assemblerze, skoro mapa jest taka nieoptymalna :/
Jeżeli usuniesz mapę, to nie będziesz musiał nic pisać.
Chwila... próbujesz mi teraz powiedzieć że moja implementacja ma milion dziur? Czy twierdzisz że korzystanie z szybki pre-optymalizacji z możliwymi false-negative'ami jest niebezpieczne?
Chcę się upewnić, że jeżeli w hashmapie będzie wartość, to będzie ona poprawna. Ponadto po Twoim opisie wyżej odnoszę wrażenie, że optymalizujesz tylko ścieżkę pozytywną (hashmapa zwraca true), a co z negatywną? Dlaczego wartości false nie trzymasz w hashmapie? Czy to efekt przeoczenia, czy ja źle zrozumiałem Twój kod, czy może wartość false w ogóle nie występuje?
No to na prawdę nie wiem czemu twierdzisz że nie warto poświęcać czasu na dobre nazwy.
Nigdzie tak nie powiedziałem.
Mój tok myślenia można byłoby uprościć do:
- Jeżeli piszesz cache, to napisz go poprawnie (albo użyj gotowca z Guavy czy czegoś) i nazwij metodę blablaCached. Najlepiej też umieść w dokumentacji jakieś uzasadnienie, dlaczego postanowiłeś go użyć.
- Jeżeli nie piszesz cache'a per se, to napisz w dokumentacji przesłanki do użycia tej szybkiej ścieżki. Nawet proste stwierdzenie w stylu
fast check to avoid I/O operations as this seems to speed up things
też jest wartościowe, inny programista zrozumie, że niespecjalnie cokolwiek mierzyłeś i kierowałeś się intuicją, więc jak trzeba będzie to zmieniać, to nie będzie godziny myślenia „a może to zepsuje rzeczy gdzieś indziej / a może muszę robić benchmarki, czy to się wyrobi na produkcji”. Możesz też nazwać funkcjęcheckYadaYadaFastWithoutIOWithFalseNegatives
jeżeli tak bardzo chcesz.