🚀 go-pugleaf

On 2019-04-28, Roman Tyczka <noemail@because.no> wrote:

[...]

> Czy tego chcemy czy nie to systemy stają się coraz bardziej skomplikowane,
> stawia się im coraz więcej wymagań, przetwarzają coraz więcej informacji a
> hardware tanieje. Oczywiście nie można olewać algorytmiki, matematyki i
> zdrowego rozsądku, bo braku podstaw i głupoty nawet setką serwerowni się
> nie naprawi, ale zgodnie z regułą pareto wystarczy 20% nakłady by uzyskać
> 80% efektu, a te 20% to gotowe klocki w postaci chmur, bibliotek,
> frameworków - uniwersalnych, więc nie zawsze zbyt wydajnych, ale tanich,
> skalowalnych i wystarczających do realizacji zadań. 

Tu trochę się wetnę, bo mam wrażenie że moje słowa są źle interpretowane.

Nie pisałem "nie optymalizować", tylko wyważyć i przesunąć ciężar 
optymalizacji, nie robić "nadmiernej optymalizacji" ani "przedwczesnej",
ani w złym miejscu.

W dzisiejszych czasach zarówno kompilatory jak i frameworki potrafią
zrobić samodzielnie własną optymalizację i to w 99% dużo lepiej niż
przeciętny programista (ilu z nas ogarnie specyficzne własności nowoczesnych
procesorów i zastosuje odpowiednie optymalizacje pod nie?). Tylko trzeba 
poprawnie tych kompilatorów /frameworków używać.

Kompilator C++ wygeneruje optymalniejszy kod niż człowiek ręcznie 
dziubiący assemblera.

PHP4 był "sam z siebie" o wiele mniej wydajniejszy niż PHP5.0
A potem był php 5.3, 7+ - każdy z nich często niesie większe 
zmiany wydajności aplikacji w dużo większym stopniu niż 
najbardziej wymyślne poprawki uruchamianego kodu.

Doctrine nie puści setek zapytań za każdym razem kiedy je 
puścimy, tylko przeprowadza wewnętrzną analizę i optymalizacje. 
Jak już zapytałeś o jakiś obiekt przez find, to drugi raz
zapytanie do bazy nie pójdzie. Update do obiektów które się
nie zmieniły, nie zostaną wysłane "do bazy".

Ilu programistów stać na takie optymalizacje jak wyżej przy
każdym możliwym fragmencie gdy używają SQL? I o ile mniej
wydajna jest wtedy ich praca?

Warto poczytać: 
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html

I z każdą wersją kolejnych bibliotek dzieje się coraz więcej "pod maską". 
Tak, w szczególnych przypadkach można mieć potrzebę na robienie tego inaczej, 
w drobnym fragmencie bardziej wyszukanie, ale jest to już od dawna na zasadzie 
"wyjątku" a nie "reguły".

Więc z dużym prawdopodobieństwiem, o ile Twój *algorytm* nie jest
wadliwy i nie ma wyjechanej w kosmos złożoności, to nie musisz się
skupiać na bajtowych mikro-optymalizacjach, dopóki z systemu nie
przyjdzie sygnał "że gdzieś jest za ciasno".

Odnośnie moich argumentów o infrastrukturze:
Infrastruktura jest obecnie skalowalna i dużo tańsza niż jescze
10 lat temu i o wiele szybciej dostępna. Używałem tego w przykładzie
skokowych obciążeń (o których wiemy, albo umiemy je przewidzieć) a nie 
jako remedium na nieprzemyślane algorytmy.

Ale niestety trzeba wyważyć koszt pomiędzy coraz wyższymi stawkami 
programistów, coraz bardziej wysokopoziomowym kodem, a coraz niższymi 
stawkami za skalowalną infrastrukturę.

[...]

> ps. nie uważam, że serwery SQL są miepotrzebne i trzeba je do /dev/null'a
> wsadzić, jest i będzie dla nich zawsze zastosowanie, bo imho nie jest tak,
> że cały świat to docelowo będzie jedno wielkie big data. Tzn. będzie, ale
> na zasadzie łączenia w jeden wielk zbiór wszystkich malukich źródeł danych,
> a te małe źródła to będą także serwery SQL.

Nigdy nie pisałem że nie będzie. :)

Dyskusja poszła w stronę pokazywania w jaką zmierzają coraz bardziej
wydajne systemy, żeby wyraźnie pokazać trudności skalowania serwerów
SQL, ale przecież zaczęła się od tematu "gdzie lepiej optymalizować
w aplikacji (tu: opartej o doctrine) czy na bazie (tu: triggery)" 
i dlaczego Doctrine ma swoje mechanizmy jako alternatywę dla 
wspomnianych triggerów.

SQL z nami jeszcze długo będzie. COBOL też jest tu i ówdzie.
A sam mam dostęp do 30-letnich systemów w perlu i aplikacji
PHP której development zaczął się w 2002 roku i jest używana
do dzisiaj.

PS. A desktopowcy powinni patrzeć w stronę PWA, osobiście uważam,
że desktop będzie powoli ewoluował w podobne hybrydy (tam gdzie
będzie potrzebny dostęp do natywnego hardware i będą ograniczenia
przeglądarkowe).

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com