[look997]

#programowanie #webdev #javascript #html #przegladarki #firefox #chrome
Jak wygląda kwestia zajmowania pamięci dla trzeb sytuacji:

1. dwa okna/karty ze stronami.
2. dwa elementy html wewnątrz jednej strony, w jednej karcie (takie dwie strony w jednej).

Chodzi o skalowalność.
Jaki narzut zajętości pamięci ma cały dodatkowy obiekt window otwarty w przeglądarce vs dodatkowy element html z tą samą treścią, ale wyświetlony na jednej, wspólnej stronie.

tab1 tab2
win win
html html
div,div div,div

vs

tab1
win
html
div,div div,div

I tak można by testować otwieranie kolejnych kart/okien.

Czyli inaczej zadane pytanie - Co zajmuje więcej pamięci: dużo divów na jednej stronie czy ta sama ilość divów ale rozłożonych w wielu kartach/oknach.

Czy robił ktoś takie eksperymenty? Są publikacje na ten temat? Jak ich szukać?

[zwierzak40]

@look997: W przypadku Chrome każda karta to jakieś 20KB "na start".
Na pewno - pod kątem pamięci - więcej divów na jednej stronie zajmuje mniej niż ta sama ilość divów rozłożona w wielu kartach.

Raz, że nie ma narzutu niezbędnego na każdą kartę, to jeszcze przeglądarka może efektywniej kompresować i stosować inne techniki optymalizacyjne.

Weź też pod uwagę, że sam kod HTML, szczególnie po kompresji GZIP to dość niskie wartości.

[misiekkiler]

@look997: Druga opcja zajmie więcej pamięci ponieważ przeglądarka musi jakby dodatkowo "otoczyć" zawartość kart

[look997]

@zwierzak40: @misiekkiler: Zastanawiam się nad możliwościami optymalizacji tej kwestii w ramach przeglądarek i w ramach webowych aplikacji.

Jakby to dokładnie przebadać, z czego to wynika, to może coś by szło ulepszyć w tej materii.

Mnie to o tyle ciekawi, że mam koncepcję wiele kart w jednym window dla tej samej strony w wielu kartach. Mam to trochę rozpisane ale musiałbym ulepszyć opis żeby było łatwiejsze do zrozumienia, bo jak próbowałem

[LepiejWcaleNizPozno]

może jakiej niskopoziomowe API zachowujące zalety webu ale wycinające zbędną funkcjonalność, aż do poziomu wydajności natywnej aplikacji z GUI.

@look997: aktualnym problemem wydajnościowym w web devie nie jest HTML czy CSS, tylko jednowątkowy JS.

[zwierzak40]

Mnie to o tyle ciekawi, że mam koncepcję wiele kart w jednym window dla tej samej strony w wielu kartach.

@look997: Wiele kart w jednym window? Nie mam pojęcia co masz na myśli.
Ale brzmi jak jak wywracanie porządku, hierarchii i kompatybilności do góry nogami.

Ale poza tym też czytałem o wasm, że w planach jest zadbanie o skalowalność, czyli usunięcie narzutu, ale to by dało efekt tylko do użycia

[look997]

Ale brzmi jak jak wywracanie porządku, hierarchii i kompatybilności do góry nogami.

@zwierzak40: Nie, ta osoba której tłumaczyłem też tak to na początku zinterpretowała ale tam nic złego by się nie działo. Bardziej to by była trochę zmiana myślenia a poza tym prawie nie do odróżnienia, nie licząc mniejszej zajętości pamięci i procesora.

[look997]

można zaoszczędzić... 2MB pamięci. Po co?

@zwierzak40: Nie jestem pewien czy to o ten efekt chodzi.
Ja tylko wzmiankowo napisałem o kilku wątkach, nie mogę teraz tego dokładnie wytłumaczyć, tylko opisałem mniej więcej skąd zainteresowanie tematem.

[zwierzak40]

Bardziej to by była trochę zmiana myślenia a poza tym prawie nie do odróżnienia, nie licząc mniejszej zajętości pamięci i procesora.

@look997: Pamięci dużo nie zaoszczędzisz. W dodatku tylko w specyficznych warunkach (ta sama strona, w sensie domena). W przeciwnym razie to będzie poważne naruszenie bezpieczeństwa.

CPU.. Nieaktywne karty zajmują tyle co nic. A aktywna jest 1, no chyba, że na innej działa jakiś JS itp.

[look997]

Termin skalowalność

@zwierzak40: Jest możliwe że go błędnie używam. Chodzi mi o sytuację, gdzie środowisko powoduje narzut, np. elektron dla każdej appki, który sprawia że kilka appek zajmuje znacznie więcej niż by mogło.

[zwierzak40]

@look997: Dobra, to o jakim rzędzie oszczędności pamięci i CPU mowa?
(i to tylko w sytuacji gdy jest otwarta więcej niż jedna karta tej samej strony).

[look997]

Koszt tworzenia aplikacji i ich utrzymania (ich kodu) jest na tyle istotny, że widzę bardzo ograniczone pole zastosowania.

@zwierzak40: No dobra, ale tak czy tak takie technologie powstają.
Wiesz na przykład, że gdzieś trzy miesiące przed ogłoszeniem asm.js ja w pewnym miejscu pytałem o kwestię wydajności JS - odpowiadali że to niepotrzebne, robili śmieszki że to taki tryb turbo by był. i wszedł asm.js z poleceniem(?) 'use asm' :D Potem binarny WASM.

[zwierzak40]

@look997: Jasne, że powstają. Sam jestem wielkim zwolennikiem optymalizacji. Przez kilka lat pracowałem z HHVM. I korzystam z wielu nowinek.

Tylko Twój pomysł, jak sam stwierdziłeś, dotyczy przypadku dwóch tych samych stron otwartych w różnych kartach.
Nie ma tu miejsca na oszczędność CPU, a oszczędności pamięci są marginalne, maksymalnie kilka MB.

Gdybyś łączył w ten sposób różne strony - to poważnie ingerujesz w kwestie bezpieczeństwa. A te 20MB narzutu na nową kartę

[look997]

@zwierzak40: To ja się pytam. :P To ja chcę rozpoznać temat. :)

[zwierzak40]

Dodam jeszcze, że to, co w przypadku nowej karty jest narzutem 20MB i tak - w przybliżeniu - byłoby narzutem w Twoim pomyśle. Bo przecież też musiałbyś separować część rzeczy. Bo stany obydwu "wirtualnych window" mogłyby się różnić. Więc przeniósł być zarządzanie tym wszystkim na inną warstwę. W najgorszym wypadku, nawet pogorszyłaby się wydajność.

Cały czas piszę w kontekście modyfikacji przeglądarki/napisania dodatku do przeglądarki. Bo chyba tylko na tam można stworzyć to,

[look997]

Nie ma tu miejsca na oszczędność CPU

@zwierzak40: Ja mam np. Facebook, gdzie jest to co prawda wyjątkowo słabo napisane, ale jakby zrobić to co mam na myśli, to wszystko prócz samej treści było by jedno i całe czaty i inne poboczne, synchronizowane nieudolnie rzeczy byłyby jednym dla wielu kart.
Ale to nie ma co tak teoretycznie opisywać, bo nawet złożony opis może być trudny do zrozumienia a co dopiero takie ogólniki

[look997]

Ale mówię, są osobne kwestie:
1. Temat jaki mnie ciekawi w tym wątku - narzut jaki robi window (może być nawet mały, po prostu mnie to ciekawi, chcę się tego dowiedzieć)
2. Temat zbliżenia do natywnej wydajności/zajętości GUI poprzez niskopoziomowe API omijające/wycinające częściowo DOM/CSSOM. Tutaj widziałem analogię do JS->asmjs.
3. Mój pomysł wiele kart tej samej strony w jednej karcie - mam na ten temat małe opracowanie, ale nie pokazuję bo nie jest wystarczająco zrozumiałe

[zwierzak40]

@look997: No nic, powodzenia.
Ilość wyzwań jaką widzę przy takim czymś jest spora (o ile w ogóle takie coś jest wykonalne na poziomie np. dodatku do przeglądarki), a efekty małe, z sporymi potencjalnymi ryzykami z kompatybilnością.

Bo cały ekosystem musiałby zdawać sobie z istnienia "wirtualnych window".

ale jakby zrobić to co mam na myśli, to wszystko prócz samej treści było by jedno i

[zwierzak40]

2. Temat zbliżenia do natywnej wydajności/zajętości GUI poprzez niskopoziomowe API omijające/wycinające częściowo DOM/CSSOM. Tutaj widziałem analogię do JS->asmjs.

@look997: Ale tu nie ma co wycinać. HTML i CSS to języki opisu. Jedyne co można zrobić, to stworzyć nowy silnik renderujący, z alternatywnym DOM/CSSOM lub lepiej to implementujące. Ale twórcy przeglądarek ciągle wprowadzają małe fixy. Ale to zupełnie co innego niż to co proponujesz.

Jakiś rodzaj drzewa musi być. Po czymś przeglądarka

[look997]

Ale tu nie ma co wycinać. HTML i CSS to języki opisu

@zwierzak40: No nie po to napisałem DOM/CSSOM żebyś mi pisał że HTML i CSS to języki opisu. :P :D

Jedyne co można zrobić, to stworzyć nowy silnik renderujący, z alternatywnym DOM/CSSOM lub lepiej to implementujące

@zwierzak40: Nie trzeba. Mam pewną koncepcję ale na tyle słabo przemyślaną,