Aktywne Wpisy
KingaM +136
źródło: 911fbd736e504216
Pobierz
kochamajfony +265
#zwiazki #rozowepaski #niebieskiepaski
Osiągamy już chyba szczyt banki spekulacyjnej na rynku matrymonialnym. Obserwowałem dziś cała noc szczypiorkow z vifonami łazacych za rączkę z typiarami lekko 15kg+ nadwagi. Niedługo czara goryczy się przeleje i będziemy mieć potężna korektę na rynku.
Osiągamy już chyba szczyt banki spekulacyjnej na rynku matrymonialnym. Obserwowałem dziś cała noc szczypiorkow z vifonami łazacych za rączkę z typiarami lekko 15kg+ nadwagi. Niedługo czara goryczy się przeleje i będziemy mieć potężna korektę na rynku.
Aktywne Znaleziska
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
windowotwarty w przeglądarce vs dodatkowy element html z tą samą treścią, ale wyświetlony na jednej, wspólnej stronie.tab1 tab2win win
html html
div,div div,div
vs
tab1win
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ć?
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. Przeciętna
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
Komentarz usunięty przez autora
@look997: aktualnym problemem wydajnościowym w web devie nie jest HTML czy CSS, tylko jednowątkowy JS.
@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.
@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.
@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.
@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.
@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.
(i to tylko w sytuacji gdy jest otwarta więcej niż jedna karta tej samej strony).
@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
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ą
Cały czas piszę w kontekście modyfikacji przeglądarki/napisania dodatku do przeglądarki. Bo chyba tylko na tam można stworzyć to,
@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
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
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".
@look997: W scenariuszy z FB
@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
@zwierzak40: No nie po to napisałem DOM/CSSOM żebyś mi pisał że HTML i CSS to języki opisu. :P :D
@zwierzak40: Nie trzeba. Mam pewną koncepcję ale na tyle słabo przemyślaną, że nie warto opisywać.
Właśnie chodzi o to, że byłyby zachowane zalety