A Google Drive elemzése
Nemrég felvetettem kérdéseket és problémákat a Google Drive működésével kapcsolatban, amikre szakmailag értékelhető válaszokat nem kaptam. Mivel ez az alkalmazás a kliensen fut, a kódját letöltés után elemeztem, mert érdekel, a felhasználói felület egyszerűségéhez képest miért ennyire lassú és erőforrásigényes a működése.
A program két főmodulra épül, alul a Google API található, ez szépítve fél megabájt körül van, és alapfüggvényeket tartalmaz, amivel az API hívásokat el lehet végezni. E mellett található a Google általános rutinkönyvtára, ami egy gigantikus osztálygyűjtemény. A teljes programban összesen 25125-ször szerepel a
A forráskódot feltöltöttem a tárhelyemre, a Google API-hoz tartozók neve értelemszerűen api-val kezdődik, az xhr-esek pedig futás közben töltődnek be, és egymásra épülő a tartalmuk. Érdekesség, hogy az
Egy mappa megnyitásakor végeztem a mérést, a tartalmának adatai már a gépemen voltak, azaz közben nem volt hálózati forgalom. A képen megszámolható, hogy harminchét függvényhívás van egymás alatt (a tetején a két narancssárga csíkból az egyik az idősáv alatt van), és a jobb oldali görgetősáv mutatja arányaiban, hogy mennyi látszik a képernyőn. Némi számolás után kijön, hogy majdnem 140 (!) szinten egymásba ágyazott metódusláncolatot hív a program. Természetesen ez nem egyedi eset, a következő képernyőn is látszik, hogy hasonló mélységek vannak máshol is.
140.
Ezek után nem meglepő az a döntés, hogy mindent a kliensen valósítsanak meg, hisz a világ összes pénze sem lenne elég, ha a Google a saját szerverein szeretné ezt a kódot futtatni. Inkább arrogáns módon kiszervezik az egészet, azaz a felhasználóikkal fizettetik ki az infrastruktúra költségeit.
A kérdés az, hogy vajon valóban ekkora kódbázisra van szükség az adott funkciókhoz? A fenti képen látszik, hogy a mappaváltás 0,2 másodpercig tartott, ezt nagyjából lefelezhetjük, mert a teljesítménymérőnek ennyi a "többletköltsége". Ha minden információ a memóriában van, mi tart három kép megjelenítésén 0,1 másodpercig, azaz száz ezredmásodpercig? Miért van szükség ennyi függvényhívásra?
A képen láthatjuk, hogy a menü kirajzolása közben a program nyolc kérést küld el a szervernek, amiből az első öt és az utolsó három minden paraméterében megegyezik (külön-külön). Ez normális? Miért kell nyolc kérés, ha elvileg kettő elég? Miért kéne két kérés, ha eggyel is ki lehetne szolgálni, hisz sehol sincs kőbe vésve, hogy egy kérésben több válasz is érkezhet? Nem rabolok több képernyővel helyet, így a következőt csak linkelem, ami a menünyitás erőforrásfelhasználását mutatja. Egyrészt ezen is látszik, hogy több mint száz szinten vannak az osztályhívások egymásba ágyazva, másrészt van rajta a jobb oldalon egy másik zöld sáv, ami két másodperccel a menü megnyitása után fut le. A menü megnyitásakor az egyik menüpont szürke, letiltott, és két másodperc után válik kattinthatóvá – a menü minden megjelenítésekor! És ezért az egy menüpont-engedélyezéshez minden alkalommal harminc ezredmásodpercig dolgoztatja a processzort (nanoszekundumok helyett).
A kódba belenézve feltűnhet, hogy a HTML sablonok és a javascript nem különül el, így, ha bármelyik változik, az egész modult újra le kell tölteni. 2003 körül indult el az a trend, hogy válasszuk külön a működést a megjelenítéstől, akkor kezdtek el külön JS és CSS fájlokba dolgozni a fejlesztők. Most ismét keveredik a szezon a fazonnal – hova is fejlődtünk akkor az utóbbi tizenöt évben?
Emellett a nyelvi feliratok is a függvényekbe vannak helyettesítve, azok cseréjekor ugyancsak az egész modult újra kell generálni és újra le kell tölteni.
"Érdekesség", hogy az
Az én gépemen nyolc másodperc után használható az alkalmazás, de a múltkori mérés képernyőképén látszik, hogy tizenhat másodpercig dolgozik a négy mag. Ennek az oka valószínűleg a javascript szemétgyűjtős módszere, azaz egyrészt rengeteg objektum van a memóriában, másrészt ezek csak rövid ideig élnek, és rövid időn belül ki kell őket takarítani. A Windows feladatkezelője szerint egyébként a Google Drive körülbelül nyolcvan megabájt memóriát foglal a Chrome böngésző 63-as verziójában.
Az Androidos telefonomról letöltöttem a Google Drive alkalmazás apk fájlját, belekukkantottam, és átnéztem a tartalmát, de nem találtam nyomát annak, hogy a webes alkalmazás kódja lenne benne, hanem natív program van benne (ez persze látszik a felhasználói felületen is). Tehát a Google mérnökei számára nem volt elfogadható a webes kliens bizonyos szempontokból, így megírták még egyszer, valamint feltételezem, hogy iOS-re is külön fejlesztettek. Így három klienssel háromszoros fejlesztési és karbantartási költsége van az anyacégnek, relatíve többször annyi idő elkészíteni az egészet, ahelyett, hogy egyszer csinálták volna meg a webre jól, amit aztán mobilon webview-ban lehetne használni, és csak azt írnák meg natívan, amire valóban szükség van.
Már jóideje nem olvasok mobiltelefonteszteket, mert egyrészt nincs bennük semmi izgalmas, meg unalmas azt olvasni minden fórumban, hogy egy-két naponta tölteni kell őket, azaz az ember állandóan azon izgulhat, hogy mikor merül le, és akkor nem tudja használni az eszközt. És miért van ez? Mert olyan jellegű metodikával készülnek rájuk a szoftverek, mint a Google Drive.
Egy mammutcégtől nem várhat az ember mást, mint egy nagy, merev szerkezetű programot, ezért ezen a területen nyugodtan lehet versenyezni velük, mert méretükből adódóan sosem fogják utólérni a konkurenciát, technológiában nem nehéz megverni őket.
■ Adatok
A Google Drive egy teljes egészében a kliensen futó program, ami egy API-n keresztül kommunikál a Google szervereivel, ahol a feltöltött fájlokat tárolják. A minifikált forráskód mérete nem sokkal egy megabájt felett van, ami egy szépítés után 4,5 megabájtra hízik, természetesen a rövid változónevekkel, így az eredeti kód megjegyzések nélkül szerintem öt-tíz megabájt körül lehet.A program két főmodulra épül, alul a Google API található, ez szépítve fél megabájt körül van, és alapfüggvényeket tartalmaz, amivel az API hívásokat el lehet végezni. E mellett található a Google általános rutinkönyvtára, ami egy gigantikus osztálygyűjtemény. A teljes programban összesen 25125-ször szerepel a
function( karakterlánc, azaz nagyjából ennyi osztály- és metódusdeklarációval dolgoznak. Az osztályok számát ebből csak becsülni lehet, az xhr.03.js-ben (lásd alább) mindegyik egy try ... cache {} blokkban van (nem mindenhol így oldották meg), amiből így ott 4743 függvényre 239 jut, azaz egy osztálynak átlagosan nagyjából tizenkilenc metódusa van. Ez az egészre arányosítva nagyjából 1250 osztályt jelent.A forráskódot feltöltöttem a tárhelyemre, a Google API-hoz tartozók neve értelemszerűen api-val kezdődik, az xhr-esek pedig futás közben töltődnek be, és egymásra épülő a tartalmuk. Érdekesség, hogy az
adatok.json-ban (én neveztem el így) van az az adatstruktúra, ami leírja, az adott mappának mi a tartalma, valamint egyéb metaadatokat tartalmaz. Ennek a megjelenítéséhez kell a többmegabájtnyi kód.Összetettség
Ki az, aki ezt a komplexitást képes átlátni? Több jel mutat arra, hogy ez a készítőknek sem megy, például azapi.1.js és az api.4.js körülbelül 50-100 bájtban tér el (amik paraméterek, a kód megegyezik). Mivel a legtöbb metódus rövid, pár soros, nyilvánvaló, hogy az egész egy gigantikus (fordított) fastruktúrába van szervezve. Ez azt jelenti, hogy az alsó szinteken lévő osztályok/metódusok nagyon mélyen vannak, szerencsére a modern böngészők hibakeresőjében ezt vizuálisan is követhetjük:Egy mappa megnyitásakor végeztem a mérést, a tartalmának adatai már a gépemen voltak, azaz közben nem volt hálózati forgalom. A képen megszámolható, hogy harminchét függvényhívás van egymás alatt (a tetején a két narancssárga csíkból az egyik az idősáv alatt van), és a jobb oldali görgetősáv mutatja arányaiban, hogy mennyi látszik a képernyőn. Némi számolás után kijön, hogy majdnem 140 (!) szinten egymásba ágyazott metódusláncolatot hív a program. Természetesen ez nem egyedi eset, a következő képernyőn is látszik, hogy hasonló mélységek vannak máshol is.
140.
Ezek után nem meglepő az a döntés, hogy mindent a kliensen valósítsanak meg, hisz a világ összes pénze sem lenne elég, ha a Google a saját szerverein szeretné ezt a kódot futtatni. Inkább arrogáns módon kiszervezik az egészet, azaz a felhasználóikkal fizettetik ki az infrastruktúra költségeit.
A kérdés az, hogy vajon valóban ekkora kódbázisra van szükség az adott funkciókhoz? A fenti képen látszik, hogy a mappaváltás 0,2 másodpercig tartott, ezt nagyjából lefelezhetjük, mert a teljesítménymérőnek ennyi a "többletköltsége". Ha minden információ a memóriában van, mi tart három kép megjelenítésén 0,1 másodpercig, azaz száz ezredmásodpercig? Miért van szükség ennyi függvényhívásra?
Egyéb furcsaságok
A Google Drive-ba való bejelentkezés után az egyes elemekre kattintva helyzetérzékeny menüt kapunk.A képen láthatjuk, hogy a menü kirajzolása közben a program nyolc kérést küld el a szervernek, amiből az első öt és az utolsó három minden paraméterében megegyezik (külön-külön). Ez normális? Miért kell nyolc kérés, ha elvileg kettő elég? Miért kéne két kérés, ha eggyel is ki lehetne szolgálni, hisz sehol sincs kőbe vésve, hogy egy kérésben több válasz is érkezhet? Nem rabolok több képernyővel helyet, így a következőt csak linkelem, ami a menünyitás erőforrásfelhasználását mutatja. Egyrészt ezen is látszik, hogy több mint száz szinten vannak az osztályhívások egymásba ágyazva, másrészt van rajta a jobb oldalon egy másik zöld sáv, ami két másodperccel a menü megnyitása után fut le. A menü megnyitásakor az egyik menüpont szürke, letiltott, és két másodperc után válik kattinthatóvá – a menü minden megjelenítésekor! És ezért az egy menüpont-engedélyezéshez minden alkalommal harminc ezredmásodpercig dolgoztatja a processzort (nanoszekundumok helyett).
A kódba belenézve feltűnhet, hogy a HTML sablonok és a javascript nem különül el, így, ha bármelyik változik, az egész modult újra le kell tölteni. 2003 körül indult el az a trend, hogy válasszuk külön a működést a megjelenítéstől, akkor kezdtek el külön JS és CSS fájlokba dolgozni a fejlesztők. Most ismét keveredik a szezon a fazonnal – hova is fejlődtünk akkor az utóbbi tizenöt évben?
Emellett a nyelvi feliratok is a függvényekbe vannak helyettesítve, azok cseréjekor ugyancsak az egész modult újra kell generálni és újra le kell tölteni.
"Érdekesség", hogy az
xhr.03.js-ben a következőt találjuk a 30628.sorban: "Ünnepelje a sokszínűséget és az LMBT-ket a Google-lal.". Nem igazán értem, hogy miért kell politikai üzeneteket beletenni a kódba, és ezek után kérdés, hogy hány ilyen van még benne, és minek terhelnek ezzel bárkit?Pazarlás
A fenti számokat látva válik egyértelművé, miért tart annyi ideig a Google Drive betöltése a böngészőben: a több mint ezer osztályt és a nagyjából huszonnégyezer metódust először definiálni, majd pedig példányosítani kell a memóriában. A számítástechnikában minden egyes absztrakcióért sebességgel kell fizetni (az egyéb veszteségen felül).Az én gépemen nyolc másodperc után használható az alkalmazás, de a múltkori mérés képernyőképén látszik, hogy tizenhat másodpercig dolgozik a négy mag. Ennek az oka valószínűleg a javascript szemétgyűjtős módszere, azaz egyrészt rengeteg objektum van a memóriában, másrészt ezek csak rövid ideig élnek, és rövid időn belül ki kell őket takarítani. A Windows feladatkezelője szerint egyébként a Google Drive körülbelül nyolcvan megabájt memóriát foglal a Chrome böngésző 63-as verziójában.
Az Androidos telefonomról letöltöttem a Google Drive alkalmazás apk fájlját, belekukkantottam, és átnéztem a tartalmát, de nem találtam nyomát annak, hogy a webes alkalmazás kódja lenne benne, hanem natív program van benne (ez persze látszik a felhasználói felületen is). Tehát a Google mérnökei számára nem volt elfogadható a webes kliens bizonyos szempontokból, így megírták még egyszer, valamint feltételezem, hogy iOS-re is külön fejlesztettek. Így három klienssel háromszoros fejlesztési és karbantartási költsége van az anyacégnek, relatíve többször annyi idő elkészíteni az egészet, ahelyett, hogy egyszer csinálták volna meg a webre jól, amit aztán mobilon webview-ban lehetne használni, és csak azt írnák meg natívan, amire valóban szükség van.
Már jóideje nem olvasok mobiltelefonteszteket, mert egyrészt nincs bennük semmi izgalmas, meg unalmas azt olvasni minden fórumban, hogy egy-két naponta tölteni kell őket, azaz az ember állandóan azon izgulhat, hogy mikor merül le, és akkor nem tudja használni az eszközt. És miért van ez? Mert olyan jellegű metodikával készülnek rájuk a szoftverek, mint a Google Drive.
Ítélet
Meg lehetett volna írni jobban? Nem kétséges. Ha egy tízelemű menü kirajzolása egy mai hardveren és modern böngészőben tizedmásodpercekben mérhető, akkor ott óriási problémák vannak. A Google mérnökei egészen biztosan dilettánsak, ha nem tudják ezt jobban megcsinálni. Az, hogy a Google Drive-nak legalább két kliensprogramja van, rengeteg plusz költséget okoznak a fejlesztői a cégnek. Ez az óriási osztálystruktúra egyrészt rengeteg memóriát igényel, nagyon kevesen látják át, és mivel egymásra épülnek a modulok, rendkívül lelassítja a fejlesztést, hogy ha egy helyen megváltoztatnak valamit, annak nagy hatása van az egészre. Továbbá, mivel a fő modulok nagyon nagyok, ha megváltoznak, a böngészőnek az egészet le kell tölteni, így valószínűleg nem túl sűrűn adnak ki hibajavításokat.Egy mammutcégtől nem várhat az ember mást, mint egy nagy, merev szerkezetű programot, ezért ezen a területen nyugodtan lehet versenyezni velük, mert méretükből adódóan sosem fogják utólérni a konkurenciát, technológiában nem nehéz megverni őket.
Miért?
Ha valóban tudnál csinálni egy hatékony konkurenciát a Google Drive-nak, akkor szerintem nagyon hamar komoly támogatók állnának be mögéd. Csináld meg! Közben várhatóan olyan problémák is fel fognak merülni amelyre elsőre nem gondolnánk. Amitől az oldal lassabb lehet. Ám, ha még azután is hatékony marad a kód, akkor a projekt még sikeres lehet!
Engem nagyon meglepne, ha erre a cikkre kapnál „szakmailag értékelhető válaszokat”. Ahogy az előző is, a cikk maga nem képvisel szakmaiságot. Ehhez csak így lehet bekapcsolódni.
Amúgy legalább annyi poént megtehettél volna, hogy a http://www.hidvegi.net/gd/ oldalon elérhetővé tetted volna a szóban forgó fájlokat. Menj el marketinget tanulni! Vagy bármit, de próbálj meg hatékonyabban kommunikálni, mert ezzel csak az amúgy is komolytalan WL-t húzod tovább lefelé...
Sikeres projektek lényegtelen
Te, Túri Gábor, mit tudsz felmutatni? Tudsz jobbat alkotni, mint a Google?
működik?
Ezt eddig még nem láttuk.
Bár most nem velem, de ismét személyeskedsz, ezzel nagyon rossz úton jársz Gábor.
»Nekem miért sikerült 58
Működik? Lehet fájlokat fel- letölteni, szinkronizálni, másokkal megosztani, google sheet, google doc - csak hogy a legfontosabbakat kérdezzem.
És Te érted?
Ez a baj. Érted?Nem, nem
Én azt kritizáltam, hogy túl sok elemet használnak.
---
Nos, számomra most is úgy látszik, hogy bizony keményen fikáztad az egészet.
És most kérlek ne menjünk abba bele, hogy ebben a mondatban nem szerepel a "hülye" szó...
ismét személyeskedsz, ezzel
Személyeskedés: "Egy álláspont vagy egy állítás helyességét a kijelentő személye, vélt vagy valós személyiségjegyei vagy feltételezett érdekei alapján próbáltad meg kétségbe vonni."
Ez alapján pontosan hol személyeskedek, tudnál idézni? Jó lenne, ha ezt tisztáznánk, mert különben kénytelen vagyok azt hinni, hogy te pedig lejáratni próbálsz engem.
Igen
SZERK.:
Vicc nélkül: személyesen veled semmi problémám nincs, a nézőpontod, érvek nélküli érvelésed helytelen.
Ahogy TG is jelezte: pozitív példákkal és hozzáállással sokkal többre mennél.
Emellett ha felvetődik valakinek valamilyen konkrét szakmai problémája, abban készséggel segítesz, ez tök jó, ezt a fajta fikázós - lenézős dolgot kéne valahogy egészen másképp, vagy nem- csinálni.
Én kérek elnézést!
Nem értem, hogy a mit tettem én le az asztalra hogy jön ide? Biztatlak, hogy valamit tegyél te az asztalra, de ezt csak akkor tehetem, ha már valamit én is letettem?
Én nem fikáztam annyit, szerintem ennyivel előrébb vagyok! :)
Anno írtam cikkeket, amelyeknél pont az volt a lényeg, hogy megnéztem eszközöket, majd amelyek tetszettek, azokról írtam egy ajánlást. Pozitív üzenetek! Tényleg ajánlom neked is! Az én világmegváltási igényemnek ennyi pont megfelelt. Igaz nekem annyival könnyebb, hogy én nem érzem azt a frusztrációt, hogy mindenki szembe megy velem az autópályán…
Amúgy tényleg hihetetlen destruktív tudsz lenni, miközben pont ezt kifogásolod. Elolvastam a cikket, emiatt tudom, hogy vannak fájlok, ám ha már egy mappa megjelenítő mintaoldalt csinálsz, akkor szerintem ötletes lenne összekötni a kettőt. De persze mit pofázok én bele…
Biztatlak, hogy valamit
Képzeld el, hol tartana a világ, ha nem lett volna majom, aki ne unta volna meg a banánt. Inkább azt gondolta volna, hogy "inkább megeszem ezt a banánt, így nem érzem azt a frusztrációt, hogy mindenki szembe megy velem az autópályán".
Vagy mondjuk a középkorban Kolumbusz azt mondja, hogy "inkább hiszem azt, hogy a Föld lapos, így nem érzem azt a frusztrációt, hogy mindenki szembe megy velem az autópályán".
És nem lesz a legtöbb másképp gondolkodóból Kolumbusz, sokan leesnek a világ széléről. De ha senki sem indul el Nyugat felé, mert az autópályák kelet fele visznek, akkor sosem fedezzük fel az Új Világot.
---
És még mindig érdekel, hogy mi és hol nem szakmai szerinted abban, amit leírtam.
Szakmaiatlanság
Viszont itt érzek egy zsákutcát, számomra az előbbiek evidensnek tűnnek. Ezzel szemben viszont te úgy látod, hogy megfogalmaztad a lényeget és minden más csak mellébeszélés. Itt most nem látom a kompromisszumos köztes verziót.
Szerintem ez olyan, mintha azt néznénk, hogy a roller vagy a repülőgép a jobb? A rollerrel sokkal gyorsabban át tudok menni a szomszédhoz. Ráadásul még olcsóbb is. Így hát mindenki hülye, aki bármire is használná a repülőgépet. Főleg a Google, mert őket trendi szidni. Ne hidd azt, hogy a Google szidásával nem tartozol semmilyen nyájhoz. És, ha már választani lehet, akkor szívesebben tartozok a technikai újdonságok iránt fogékonyak csoportjához, mint az utáljuk együtt az XY-ékat csoporthoz. Ám visszatérve a példádhoz, egy statikus html oldalt hasonlítasz össze egy olyan oldallal, ahol közel valós időben változik a tartalom. Nulla jelentősége van, hogy hány div-ből épült fel, nem ezen múlik a sebesség. Szerintem a felhasználói élmény javításához nem a div-ek számát kell csökkenteni.
Különben olyan érzésem van, mint amikor egyesek politikáról vitatkoznak. Mindenki hisz a saját igazában, mondja a saját hülyeségét, majd nem érti, hogy a másik miért nem érti és elmondja ismét ugyanazt. Kicsit más köntösbe, de lényegében semmi újat nem hozzáadva. Szerintem ezek a beszélgetések sem tudnak kilépni ebből a hibából...
Szakmaiság
És igenis számít, hogy hány elemből áll egy blokk, mert ha valamihez hússzor annyit használnak fel, amennyi kell, ahhoz a szükséges többszörösét kell dolgozni.
És ha a szükségesnél több elemet használnak fel, akkor mi garantálja, hogy más munkafázisoknál sem bánnak pazarlóan?
Ebben az elemzésemben pedig rámutatok, hogy nem egyedi eset, hogy valamit többször csinálnak meg feleslegesen, például ugyanazt a javascript kódot többször töltik be, ugyanazt a kérést elindítják nyolcszor stb.
Ezek mind egy mintázatot mutatnak, amiből lehet következtetéseket levonni.
Álláspont
Ám nekem elfogytak az érveim. Én azt mondom, hogy elsősorban nem a divek számával kell spórolni, te azt, hogy igen. Közben látunk egy sikeres példát, ahol nem a html méretén spóroltak és látunk egy mintaoldalt, ahol a működés nem lett elkészítve. Szerintem ez összehasonlíthatatlan. Ez ebben a formában már hitvita, mindenki azt lát bele, amit szeretne. Én speciel azt, hogy nem működik a mintaoldal. Nincs mit elemezni ezen.
Igen, ezzel kezdted, de nem
Én ezzel szemben leírtam, hogy miért fontos vele foglalkozni: mert mobilon egyrészt korlátozott az akkumulátorok kapacitása, másrészt korlátozott lehet a mobilnet.
Az, hogy a Google Drive pénzügyi szempontból sikeres, technológiai szempontból teljesen irreleváns. A weblabor egy szakmai portál, és nem is értem, hogy miért ne lehetne szakmailag kritizálni őket? Ez hülye érv.
magadnak mondasz ellen,
Most akkor az sem jó, ha mobilra van arra optimalizált megoldás és az sem, ha ugyanaz fut mobilon is?
Ártatlanság vélelme
Én azt mondom, hogy a html mérete nem lehet elsődleges. Nem azon kell spórolni. Amit te úgy kódoltál le magadnak, hogy szerintem a sebesség nem lényeges. Ugye abban egyetértünk, hogy ez a következtetés igencsak téves? Jóhiszeműen csak egyszerűn tévesnek nevezem, de talán szándékos csúsztatásnak is nevezhetnénk?
De, akkor mégegyszer. A teljes projektben a sebesség nagyon sok szempont alapján alakul. Ebből a nagyon sok szempontból a html mérete egy elenyésző egység. Legtöbb esetben egy SPA optimalizálás nem a html méreténél kezdődik. Ebben egyetértünk, vagy ezzel sem?
Viszont te mást nem hasonlítottál össze. Csak a html méretét. Amikor arról írsz, hogy az eredeti 900 elem helyett 58-ból sikerült megalkotnod ugyanazt, akkor nem azért írtad ezt, mert szerinted ez egy követendő hozzáállás? Nem azért írtad, hogy jó az, ha az elemek számát minimalizáljuk? Más szavakkal, hogy a divek számával spórolni kellene? Nem igazán értem, hogy miért kérdezel vissza, hogy hol állítottál ilyet? Nem erről szól a minta oldalad? Az általad készített összehasonlítás nem erről szól, hogy ha meg lehet csinálni kevesebb html elemből, akkor szerinted azt kevesebb elemből kell megcsinálni? Vagy valamit akkor nagyon félreértettem. :)
Félreérted
Súlyos vádakat hoztam fel, és ezt meg is indokoltam, ha olvastad az írást, akkor találkoztál is vele. De szívesen megismétlem a kedvedért: a fő ellenérvem az, hogy a Google Drive-nak legalább két kliensprogramja van, egy webes és egy Androidos, és a kettő nem ugyanazt a kódbázist használja.
Ez azt jelenti, hogy a webre leprogramozott kliens nem alkalmas mobilon való használatra, pedig ma már minden technológia adott ahhoz, hogy böngésző alapú, offline is működő mobilos alkalmazásokat készítsünk.
Ha a képernyőn ugyanazt a kinézetet huszadannyi HTML elemből is meg lehet valósítani, akkor az azt jelenti, hogy húszból tizenkilenc elem nem látszik. Akkor jön a kérdés, hogy ha egy elem nem látszik, akkor miért kerül legenerálásra? Hússzor annyi elem legenerálása hússzor annyi munkát ad a processzornak, de miért is jó ez, ha ennek csak az egyhuszada látszik? Ráadásul az egésznek a sablonját is jóval több munka létrehozni.
Lehet, hogy az én kódomon is lehet javítani. Ha így van, akkor megteszem.
Az én verzióm
Több helyen kimutatták már, de ajánlom, hogy akkor vizsgáld meg ezt is: Sokkal gyorsabb egy dom-ben lévő elemet megjeleníti, majd eltüntetni, mint a dom-ba betenni, majd kivenni egy elemet. Elején bekerül, további 1 másodperc az elején, majd a következő 10 percben minden gyorsabb lesz.
És valójában a megás js fájl betöltése sem 2 másodperc, 900 html elem felépítése nem fogja meg a procit, az ügyfél észre sem veszi, hogy a kezdőképhez képest mik történtek a háttérben. Én nem ismerem a Drive felépítést, nem tudom, hogy miért kell az ikonnak két div, ahogy írtad. De, hogy ebből lekövetkeztetni, hogy biztos dilletáns a készítő azt erős túlzásnak érzem.
A működés sebessége nem függ a html dom méretétől. A beszúrás és törlés költségesebb, mint a nem megjelenítés. Ám itt sem egyértelmű a kép, irreálisan hosszú html nem jó. Ez is igaz. Persze. De nem 900 elemnél kezdődnek el a gondok!
Optimalizáláskor például megnézhetjük az Ajax hívások gyakoriságának szükségességét. Cachelhetünk-e bármit is? Igen, még több infó a memóriába. Össze lehet-e vonni Ajax hívásokat, vagy adott esetben ketté lehet-e szedni, ha az úgy jobb? Az eseménykezelésen hihetetlen sokat lehet agyalni. A konténer elem kapja el a kattintást és utána vizsgáljuk, hogy mely elemre kattintottak, vagy minden elem kapjon önálló kattintás eseményt? Nagy elemszámnál ez sokat tud segíteni. Adott esetben a kód egyszerűsítéséhez is vezethet, ami egyéb okból lehet hasznos. Én minden egyes képet összenyomok, amennyire csak lehet. Túl magas labda, de nem bírom nem lecsapni. A minta oldalon ez kimaradt, például az ikon_listanezet.gif esetén a 1318 bájt helyett elegendő lenne 93 bájt. Úristen, vajon a honlap további része is ennyire pazarló??? 14-szeres a különbség!!! Igen, pontosan tudom, hogy sikerült kiemelnem egy totál lényegtelen részt, de szeretném a hasonlóságot hangsúlyozni!
Gyorsaság
De mi van akkor, ha az illető nem fog az elemmel interakcióba lépni? Például nem kattint rá, mert nem érdekli a tartalma. Akkor miért generálnék le előre bármit is?
Erre annál nagyobb az esély, minél több elem van az oldalon. Ugyanis két eset lehetséges: vagy csak bizonyos logikai elemekkel fog dolgozni (a Drive-ra levetítve: mappákkal, fájlokkal), vagy minddel. Ez utóbbi esetben tudunk csoportműveleteket létrehozni, például az összes fájl letöltése egyben. Tehát az esetek többségében nem fog semmit sem csinálni az elemek egy részével.
Végeztem egy mérést, egy saját oldalamon egy negyven elemből álló dialógusablak legenerálása alkalmazáslogikával, sablonozással együtt 10ms az Atomos gépemen. Úgy gondolom, hogy ez jó viszonyítási szám.
Megnéztem, a Google Drive-on a mappa ikonjához 30 elemet használtak fel (nekem 3-ból sikerült ugyanaz). Tegyük fel, hogy tényleg mind a harmincra szükség van; mennyiből tartott volna nekik is három elemet legenerálni az elején, és a harmincat akkor, ha valaki interakcióba lép vele?
Az átlagember reakcióideje egytized másodpercnél kezdődik, ami 100 ms. Gyakorlatilag senki sem venné észre, ha a három elemből álló elemet lecserélnénk a harmincasra.
Ez is egy járható út. Így az eredeti 14x30=420 helyett 14x3=42 elem elkészítése is elég lett volna. Sok kicsi sokra megy.
Hány helyen lehetett volna még hasonlóan spórolni?
Ugyancsak emberi tényező, hogy nem vagyunk gépek, azaz nem folyamatosan gépelünk, kattintgatunk, hanem közben gondolkodunk, megiszunk egy kávét, azaz rengeteg a holtidő.
Ha már nagyon előre be akarunk tölteni mindent a memóriába (aminek én személy szerint nem látom sok értelmét, de a vita kedvéért tegyük fel, hogy így jó), miért nem lehet például ezekben a holtidőkben ezt a betöltötetést elvégezni?
Én rendkívül kicsi esélyét látom annak, hogy valaki egyszerre szeretne térképet nézni, közben excel táblát és word dokumentumot tervezni. Ezt egyébként nagyon jól lehet mérni. Szóval érdemes-e mindent előre betölteni és inicializálni, ha nincs rá valós szükséglet?
Következik-e ebből bármi?
Nem értem
Írtál lentebb egy példát. Ha abban a quantity értékét 100-ról 10-re csökkentem, akkor gyorsabb vagy lassabb lesz a futás? Nem tudod?
Persze, hogy nem.
Kérdés
Talán mert például előre gondolkodnak?
Konkrétumok
Ha nem tudsz választ adni, akkor inkább ne írj semmit.
---
Ezt az előre gondolkodást nem értem, és erre kérdeztem rá a 41-es hozzászólásban: honnét tudod, hogy azt a bizonyos dolgot fogják-e használni? Miért kell előre legenerálni, miért nem lehet akkor, amikor szükség van rá? Miért és mi alapján végeznek el előre munkát?
De a vita kedvéért tegyük fel, hogy igazad van, és a gyorstárazás miatt generálnak le előre bizonyos html kódrészleteket. Hol van a határ? Mi az, amit előre le kell generálni, és mi az, amit nem? Ha pl. egy excel tábla van a könyvtárban, akkor az ahhoz szükséges szerkesztőfelületet miért nem generálják le? Mert én erre nem találtam nyomot a html kódban. Hisz sokkal gyorsabban meg lehetne így nyitni ezt a fájlt. Ha egy word doksi is van a könyvtárban, annak a szerkesztőfelületét miért nem generálják le előre?
Szerepcsere?
Én azt állítom, hogy az "elemzésed" kevés ahhoz, hogy ilyen szintű vádakat megfogalmazzál. Ebben a felállásban nem nekem kellene bizonyítanom, hogy a Google Drive kódja jól van megírva, hanem neked kellene, hogy rosszul.
Nem megyek bele abba a hibába, hogy megvédjem a Drive kódját, amikor azt én nem ismerem. Én csupán a te irományodat látom, és abból azt szűrőm le, hogy a megfogalmazott vádaskodásaidnak nincsen alapja.
Lényegtelen
Én úgy gondolom, hogy lényeges, amiket felhoztam.
Örülök, hogy erre jártál, és várom a pozitív kicsengésű írásaidat!
Ez tényleg félreértés.
Én azt állítom, hogy fikázod az egészet, de csak egy kis részét tudtad megvizsgálni. De ezt nem szabad érdemként feltüntetned! :-) Az összehasonlítás, amire hivatkozol az a teljes Drive funkcionalitásának egy elenyésző része. Egy lényegtelen hányada. Az becsülendő, hogy szerinted lényeges rész, de nem az.
Költséghatékonyság?
Alternatíva
Semmi nem következik ebből...
Információ
Miért mit tudunk? :)
Miért gondoljuk, hogy
90%-ban egyetértek
Konkrétan a drive-al kapcsolatban is, többször elhangzott az is, amit javasolsz ("Csináld meg!"), de ami nem az elképzeléseit támasztja alá, abba vagy bele köt, ahol tud, vagy egyszerűen figyelmen kívül hagyja..
Szerintem a legnagyobb probléma a nézőpont / hozzáállás.
"Tegyük fel, hogy jó ez az irány, de hogyan lehet még optimalizálni?"
vs
"Ez így biztos, hogy szar és én egyedül is százszor jobbat csinálok."
Azt gondolom, az első lényegesen egészségesebb és azon az úton jóval több "szakmailag értékelhető" választ lehet kapni.
Nem érted
De, értem
Hogyan tovább?
A tartalomban elszórt kérdések inkább költőinek tűnnek, semmint olyannak, amire korrekt választ lehet adni (nekem például nincs időm/kedvem deobfuszkálni a drive kódját, a forrás hiányában viszont csak elméleteket gyárthatok, hogy miért X függvényhívás és Y mélységű osztályhierarchia van Z elem megjelenítéséhez).
Lehetne jobban csinálni, mint a Google? Van rá esély, és ezt szerintem senki nem vonja kétségbe. De mit kezdjünk ezzel a tudással/feltételezéssel? Fejlesszünk egy alternatívát? Írjunk egy cikksorozatot, ami bemutatja a "Better Than Google" metodológiát?
Mi a cél az ítélkezésen túl?
Gondolatébresztő
El lehet gondolkodni azon, hogy a Google vagy a Facebook technológiáját (Angular, React) használja egyre több fejlesztő. Ez a két rendszer hasonló elvekkel készült, mint a Google Drive.
El lehet gondolkodni azon, hogy az itt hozzászólókat nem zavarja a több másodperces betöltés és a több tizedmásodperces válaszidők, de korábban már sokszor volt vita a kliens- és/vagy szerveroldali ellenőrzésről, ahol a kliensoldali mellett az volt az érv, hogy gyorsabb. Most tehát akkor számít-e a sebesség vagy sem?
El lehet gondolkodni azon, hogy ha bonyolult egy rendszer, mint például a Google Drive, az mennyire befolyásolja a fejlesztési időt, mennyire befolyásolja a hibák számát.
El lehet gondolkodni azon, hogy ha a Google-nél ekkora bakikat követnek el, akkor az olvasó miért ne tudna náluk jobb szoftvert írni?
Ejnye ejnye képviselőjelölt Úr!
---
Komolyan azt gondolod, hogy csak az lehet valamirevaló fejlesztő, aki egymaga tud valami jobbat - többet, mint a gugli többezer mérnöke együttvéve?...
---
Már megcsináltam, idén fog kereskedelmi forgalomba kerülni.
Mutasd már meg idézettel légyszi, hogy hol is állítottam olyat a linkelt hozzászólásban, hogy
De marha gyorsan ám, mert már elérted azt a szintet, amivel szemben komolyabban lépjek fel.
Ezen kívül
Nyilván a drive-on is van mit / lehet mit optimalizálni, nyilván teszik is ezt nap mint nap (legfeljebb nem verik nagy dobra), nyilván akadhat benne olyan rész / részlet is, ahol ha ismernék a te javítási ötletedet, akkor jóvá is hagynák.
Ez viszont nem jelenti azt, hogy az egész hóbelefranc úgy szar ahogy van.
És ha valaki (akár én, akár más) azt meri neked mondani, hogy "azért az csak nem annyira kuka, ha egyszer sikeres", azzal az illető nem azt mondta neked, hogy "nincs annál jobb".
Figyelj má' csávó, a Pepita én vagyok, de úgy látszik neked valami vagy csak fehér, vagy csak fekete lehet, de az nagyon. :)
Találj középutat, ezt kívánom, a stílusodon meg nagyon nagyot javíts, mielőtt komolyabb baj lenne belőle.
Hát gondolkodj el
Számít a sebesség, senki nem mondta, hogy nem. Nyugodt lehetsz, a drive fejlesztőinek is számít. De például funkcionalitáson nem fognak csökkenteni azért, hogy kicsit gyorsabb legyen, mert azáltal usereket vesztenének.
Fontos a sebesség, de kérdezz körbe légyszíves a tágabb ismeretségi körödben, hogy hányan vannak azok, akik korábban használtak google drive-ot, de sebbesség-problémák miatt már nem használják, esetleg mást használnak helyette.
Itt a wl-en úgy tűnik, te vagy az egyetlen, aki elégedetlen vele.
A bonyolult rendszerekre összetettebb a munkafolyamat is, ahogyan fejlesztik, ez módszertan függő, nem feltétlenül növeli jelentősen a fejlesztési időt, viszont tisztább kódot eredményez, ami lefelé befolyásolja a hibák számát is. A hibák ellen pedig ott van még a rengeteg féle automatizált teszt, code review "hegyek", UAT, manuális teszt és még sorolhatnám.
(Nem.)
Ezek továbbra sem olyan
Szép dolog, hogy ki-ki elgondolkodik azon, ami lejön neki ezekből az írásokból (bár az ábra azt mutatja, hogy a többségnek nem az jön le, amit szeretnél), de azzal mivel leszünk előrébb? A neten továbbra is csak a "Google és társai" módszerről fog részletes leírást találni az egyszeri fejlesztő, a "Hidvégi módszer"-ről meg csak végeláthatatlan litániákban utalásokat arra, hogy túl sok a html elem/http kérés/stb., elgondolkodik rajta, majd megvonja a vállát és bevág az 5 statikus oldal alá egy éppen sokat látott módszert, és kész.
A techgigászok mutatják, hogy hogyan kell majmolni őket, te pedig a wl egy csendes sarkában ítélkezel. Ők haladnak (hogy milyen irányba, az lényegtelen, de haladnak), te pedig ugyanazokat vádakat írod le évek óta ilyen-olyan köntösben. E mellé nem lehet beállni, hogy "na, mostantól én is így csinálom", mert arra nem ad senki fizetést, ha "tudod", hogy a drive túl lassú, és kevesebb kóddal kellene megoldani.
Mutass irányt hasznos funkciókat megvalósító példákkal (nem minimalista design mockupokkal), és talán lesz, aki majd utánad akarja csinálni.
Szóval ha a célod a webes ökoszisztéma felrázása/javítása, akkor nagyon rosszul csinálod, mert a jelek szerint az olvasók többségéből csak ellenszenvet váltanak ki az írásaid és ha el is gondolkodnak rajta, olyan környezetben teszik, hogy "valaki megint ledilettánsozta a google fejlesztőket", miközben megosztja egy kirándulás fotóit a drive-on.
Félreérted
Pont az a fontos, hogy a majmolás helyett más is nézze meg, mi az, ami történik, ő azt hogyan valósítaná meg, és akkor rájön, hogy a nagy techcégek alapjában véve nagyon vacak kódot generálnak, amit nem nehéz felülmúlni.
Sokszor hangsúlyoztam már, hogy a Google egy példa, nem egy főbűnös. Mint írtam, a facebook bizonyos funkcióit megvalósítottam, például a végtelen görgetést, és ott is pont ugyanez a pazarlás megy például a felhasznált HTML elemek számában, mint a Google-nél, ugyanígy rengeteg JS kódot kell letölteni, és úgy általában, rendkívül lassú és erőforrásigényes - minden különösebb ok nélkül.
Tehát még egyszer: nem kívánok kész megoldást adni, mert akkor azt fogják másolni. Aki csak másolásra képes, az szolgának jó, de vitapartnernek nem igazán.
Mindenki jobban jár, ha gondolkodó emberekkel vagyunk körülvéve. Tehát
kezdjetek el gondolkodni!
Ezért nem éred el a célod,
Szép dolog a gondolkodás, csak azért kevesen hajlandóak fizetni.
Ez kezd egy kicsit erős lenni...
Minősítés
Aki nem akar gondolkodni, azt mennyire lehet szakmailag elismerni? Mi garantálja, hogy a Google-nál gondolkodó emberek dolgoznak?
Hülyének nézés
Szóval az állításoddal ellentétben nem hülyének nézem az olvasókat, hanem önálló, felnőtt embereknek, akiknek megvan a szabadsága az általam megosztott információk alapján, hogy döntést hozzanak a sorsukról, ha azokat relevánsnak találják.
Aki nem akar gondolkodni, azt
Nagybetűkkel kiírni, hogy gondolkodjatok emberek eléggé kimeríti a minősítés és hülyének nézés fogalmát. A komolyabb projecteken általában egyáltalán nincs, vagy nagyon limitált időd van arra, hogy olyan problémákkal foglalkozz, amikre van off-the-shelf megoldás. Amire esetleg jut időd az az, hogy kiválaszd az elérhető kész megoldások közül a szempontrendszered szerint legmegfelelőbbet. És ennek a szempontrendszernek az egyik legfontosabb pontja általában pont az, hogy sokan használják, mert az garantálja, hogy megfelelő támogatást és hibafelderítést kap a termék. SOHA nem láttam még olyat, ahol ez nem szerepelt nagyon komoly súllyal a szempontok között. Sok egyéb szempont szerint persze. Te pont ezt kérdőjelezed meg ezekben a cikkekben, és ezért támadod be az egész fejlesztői szakmát.
Ha úgy gondolod, hogy ezek a termékek rosszak, akkor állj elő a saját gyorsabb-hatékonyabb-tesztelhetőbb stb megoldásoddal, reklámozd azt a saját blogodon, hogy az miért jobb. Ha tényleg jobb, akkor sokan be fognak állni mögé és foglalkozhatsz azzal, amit láthatóan szeretnél csinálni, nő a szakmai respected és emellé kereshetsz vele még egy kamion pénzt is. Ennek amit itt csinálsz semmi értelme nincsen, és nem mondasz vele semmit senkinek, csak a saját szakmai ázsiódat ásod alá.
Jobb
Az a legbonyolultabb űrlapunk, 800 elemből áll, a renderelése 500ms körül van, ennek a nagy része beviteli mező, aminek a létrehozása kétszer annyi, mint egy szimpla div-é.
Ehhez a kliensprogramunk 59 kilobájt. És mi is tudunk többek között fájlokat, mappákat menedzselni.
Tehát vannak-e más utak, amikkel szoftvert lehet fejleszteni? Tilos-e kritizálni mások munkáját?
Az, hogy ide írok néha valamit, jelenti-e azt, hogy csak az én fantáziám szüleménye, vagy pedig meglévő tapasztalatok alapján próbálok rámutatni az alternatívákra?
Származhat-e bárkinek hátránya abból, ha kiderülne véletlenül, hogy van igazság azokban, amit állítok?
Látom nem akarod megérteni,
Én itt ebből kiszállok, semmi nyeresége nincs ennek a témának, teljesen ignorálsz szakmai alapvetéseket. Csak annyit tegyél meg kérlek, hogy ne az itteni fórumtársak és a szakma ostobázásával, lenézésével hangoskodva próbáld meg ráterelni a figyelmet a gondolataidra.
Kérdések
Hogyan változnak ezek a költségek, ha harmadik féltől származó, off-the-shelf szoftvert használ az ember? Ugyanis bejön az időfaktor, azaz egy külső függősége lesz, és a hibajavításokra így esetleg kiszámíthatatlan ideig kell várakozni?
A Google Drive egyébként teljesen saját fejlesztése a cégnek, azaz nem külső könyvtárakat használtak hozzá. Volt-e így választási lehetősége a készítőknek, hogy milyen úton induljanak el?
Azt azért érdemes tudnod,
A többi meg már párszor ki lett tárgyalva...
Indokolatlan...
Én írtam: "Semmi értelme indokolatlanul fikázni sikeres projekteket."
Te írtad: "T.G szerint egy sikeres projektet nincs értelme kritizálni"
És nem csak az indokolatlan szó hiányzik. Ezek a bejegyzések nem kritikák, ezek értelmetlen fikázások. Messze nem ugyanaz a kettő.
Nincs jelentősége
Én alátámasztottam az érvelésem, ha az számodra nem elfogadható indok, az a te problémád, és nem az enyém.
Valóban azt írtad, hogy "indokolatlanul", ez kimaradt az Endylnek szánt mondatomból, de a kontextusban nincs jelentősége a fentiek miatt.
Elemzés, kritika, fikázás?
A cikk címe az, hogy A Google Drive elemzése. És egy árva szó nincs erről. Pedig ezért szeretjük a Drive-t, emiatt használjuk, ez benne a jó, ez benne az érték. Az elemzésnek csúfult írásban egy teljesen lényegtelen részlet lett kiemelve. Mégpedig, hogy az alkalmazás indulásakor mi történik. De valójában még ez sem, mert nem lett ez kielemezve. Nem értetted meg, hogy mi miért történik. Ám ami még rosszabb, hogy meg sem próbáltad megérteni! Majd végül levontad a következtetést, hogy mivel nem értetted, akkor biztosan rossz az egész.
Ez nem elemzés, de még kritikának sem kritika. Ez tényleg nem több mint indokolatlan fikázás. Ami szerintem nagyon, de nagyon káros!
Gondoljuk végig
Egyébként a Google Drive pont így működik, ha megnézed a hálózati forgalmat.
Ha ez számodra "hihetetlen nagy know-how", akkor nem tudom, hogy van-e miről vitáznunk.
Említed még a biztonságot: a kliens visszafejthető, könnyebben, mint egy natív program, tehát itt semmi olyasmit nem tudnak csinálni, aminek ne lehetne utánajárni. A szerveroldali biztonság pedig a klienstől teljesen független.
Próbáld egyben
Ezen kívül tök jó lenne, ha azt próbálnád érteni, amit mondanak neked, nem azt, amit bele tudsz magyarázni.
"hihetetlen nagy know-how" - ezt nem egy 10 soros js függvényre értette TG, hanem a teljes szolgáltatásra.
Folyamatosan kiragadsz egy-egy apró részletet, amibe éppen bele tudsz kötni, de nem vagy hajlandó látni a fa mögötti erdőt.
Ahhoz, hogy az "igazadat" erősítsd, nem riadsz vissza a csúsztatott "idézetektől" sem - milyen érdekes, hogy ahol nem szó szerint idézel mást, ott többnyire van is rá jelzés, hogy "én nem ezt mondtam"...
Közben még magadnak is ellent mondasz (az is rossz, hogy natív app van és az is, ha mobilon ugyanaz, mint asztali böngészőben).
Ezért nem találsz partnerre ebben és a hasonló fikázásaidban.
Sokkal értékesebb lenne, ha olyan példákat mutatnál, amit legalább a kezdők hasznosítani tudnak, például a végtelen görgetés is érdekes lehet.
Ha ezt jól csinálod, akkor nem másolgatni fogják, hanem tanulni belőle.
Ha viszont picit belenézegetsz egy elég nagyra nőtt szolgáltatás kódjába, nem érted meg, hogy mi miért van, de lefikázod, majd pedig a többiektől várod el, hogy túrják szét nálad sokkal jobban azért, hogy elmagyarázzák neked, amiket nem értettél, különben "neked van igazad" - nos ezzel csak magadat tudod lejáratni.
Mondhatod nekem / rám, hogy én járatlak le, de attól még nem lesz igazad, hogy hangosan kiabálsz, én nem ostobáztalak / hülyéztelek le...
Próbáld megkeresni a pár évvel ezelőtti segítőkész és szerény Hidvégi Gábort, szerintem sokkal hasznosabb lenne a társadalom számára és neked is.
Próbáld megvalósítani!
Vannak olyan helyzetek, amikor felmerül, hogy vagy feleslegesen bekerül egy konténer div, vagy a forráskód csúnyább lesz. Mivel a divek számának nincs súlya, így véleményem szerint, és ebben sokan hasonlóan vélekednek, a helyes választás a szép forráskód.
Ám amíg csak egy statikus html oldalt készítesz, addig ezek a problémák fel sem merülnek. A cikkeid alapján az látszódik, hogy egyszerűen te még nem tartasz ott, hogy a valódi problémákat meglásd! Emiatt mindenféle álprobléma ellen küzdesz. Amikor meg valaki felveti, hogy nem a lényeggel foglalkozol, akkor nem érted, hogy miért. A cikkeid színvonala nem éri el azt a szintet, hogy valóban a Drive működését elemezze. Ami nem is lenne baj, ha nem vonnál le olyan következtetéseket, hogy teljesen rossz az irány, amit ők megvalósítottak.
Tényleg, próbáld megépíteni, majd amikor a 2 másodperces Ajax hívások nem hozzák ugyanazt az eredményt, akkor keres más alternatívákat. Long polling ajax hívást például.
És majd a sokadik probléma megoldása után megtapasztalhatod, hogy tényleg volt ott tudás.
Vagy persze akár küzdhetsz a szélmalmokkal is tovább, nekem végül is mindegy! :-)
Mivel a divek számának nincs
Számok
Persze, hogy meg lehet oldani. Látjuk, hogy a Google Drive-nak is sikerült. Ha probléma van, akkor az csupán annyi, hogy jelenleg nem rendelkezünk olyan összehasonlítással, mely segítségével a kód milyenségéről bármit is lehetne mondani.
Hibás mérés
gomb_klikkutolsó parancsa most egydocument.titlemetódushívás, kattints párszor a gombra, és nézd meg, mekkora számok jönnek ki a címsorban, nálam Chrome 64-ben átlagosan 1390ms körüli értékek.Aztán kommentezd ezt a sort, és vedd ki a kommentezést a setTimeout elől, és utána nézd meg az eredményt: nagyobb lesz. Miért? Mert a függvényen belül csak a DOM fát módosítod, de a böngésző még elvégez a függvény befejezése után egy műveletet, amit nem mérsz, a kirajzolást.
Ez nálam átlag 1515ms-re módosítja a fenti számot. Ez ráadásul függ attól, hogy az elemeknek milyen stílusa van, azaz, ha a
<style>elemben kiveszed a kommentezést, még nagyobb lesz az érték, nálam 1600ms körüli.Lemértem, a mi rendszerünkben a ~ 800 elemes űrlapon az elemek fájának összeállítása és DOM-ba szúrása 140ms körül van, de a teljes rajzolási ciklus (setTimeout-tal) már 500 körül. Azaz ennyit számít, hogy nem szimpla
<div>-eket teszünk a képernyőre, hanem stílusozott elemeket.És hogy lehet az, hogy a 800 elemet 140ms legenerálni, míg a fenti példában a 2300-at a tízszerese? Azért, mert az utóbbiban egymásba vannak ágyazva, azaz az elemek egymáshoz viszonyított pozíciója is számít a számukon kívül.
Ezért érdemes az elemek számával spórolni.
Szerintem megint szellemekkel küzdesz.
Következmények
Nyilván a stílusomon még elég sokat kell csiszolni (vagy baltával faragni), bár ez a tényen nem változtat, hogy alapvetően igazam van.
Számodra tanulság lehet, hogy teljesítménymérésben még nem vagy tökéletes. Továbbá a koncepcionális hibák kiszúrásában is érdemes elmélyülnöd, én ma reggel jöttem rá, hogy a kódomban egy elég nagy baki van:
Ezért ha lecseréljük a következőre:
setTimeout-tal mérünk, akkor 225 lesz, azaz 200ms a kirajzolás.Miért tartom fontosnak az elemek számát? Mint korábban írtam, önmagában ez az adat nem hordoz információt, de ha annak fényében nézzük, hogy[list]