ugrás a tartalomhoz

A mundér becsülete

Hidvégi Gábor · Feb. 6. (K), 22.26
Pár nappal ezelőtt egy másik témában kezdtem a szálat, de úgy gondolom, ez többet érdemel, ezért kihoztam ide, hátha közösen sikerül találni a felmerülő kérdésekre választ.

A probléma alapvetően a modern fejlesztési elvekkel van, amit a Google Drive példáján illusztrálok. Ezen a linken található egy tárhely hét mappával és hét fájllal, erről a biztonság kedvéért készítettem képernyőképet is:



Mint látható, a kezelőfelület végtelenül egyszerű, viszont a betöltése a négymagos Atom processzoros gépemen nagyjából nyolc másodpercnek érződik. Ez az idő frissítés után sem csökken, sőt, készítettem egy képernyőképet a processzorhasználatról:



A kicsinyítés miatt egy függőleges csík lemaradt, de ez az eredményt nem befolyásolja. Az ábrán egy percnyi processzorterheltséget láthatunk, egy oszlop, ami 10 másodpercet jelez, 38 pixel széles, és kiszámolható, hogy a "hegy" lábánál nagyjából 62 pixel széles idősávban történt a Google Drive betöltése a böngészőben. Ez 62/38*10 = 16,31 másodpercet jelent, ennyit dolgozik a processzor az oldal betöltésekor.

Jó kerekítéssel mind a négy mag 50%-os terheltségen ment, ami megegyezik azzal, mintha két mag 100%-on dolgozott volna ennyi ideig, vagy egy mag 32,63 másodpercig. Ez 1,3 Gigahertz-cel számolva 42,42 GHz teljesítményt jelent.

Mi tart ezen ennyit?

Mint láthatjuk, az oldal végtelenül primitív, alig van rajta pár elem; a css nagyjából 100 kilobájt, azt kissé sokallom, de ráfogom, hogy rendben van; a képek mérete nagyjából 11 kilobájt a fejlesztői eszközök szerint.

Viszont lejön összesen 1,3 megabájtnyi "minifikált" javascript, ami szerintem rengeteg. Miért szükséges ennyi script ilyen kevés elem megjelenítéséhez? Miért szükséges bármilyen javascriptre egy ilyen egyszerű oldal megjelenítéséhez?

Doppelgänger

Elkészítettem az oldal mását demonstrációs célból. Nem volt célom a pixelpontosság, nem volt célom a funkciók lemásolása, csak arra voltam kíváncsi, hány elemből lehet elkészíteni azt, amit a Google Drive megnyitásakor látok.

Az eredmény, miután a konzolban lekértem a document.body.getElementsByTagName('*').length értékét: 58 elem. Ehhez képest a Google Drive-on ugyanezt lefuttatva 938-at kapok.

Miért?

Miért kell a Google-nek majdnem hússzor annyi elem ugyanannak a tartalomnak a megjelenítéséhez? Igaz, kihagytam pár placeholdert, valamint néhány grafikánál nem SVG-t, hanem képet használtam, de ezeket betéve a saját eredményem nem módosult volna érdemben.

A hálózati forgalmat elemezve kiszűrhető, hogy a lényegi tartalom, ami egy JSON objektum, 1750 bájtos. Ebből a Google Drive a fejlesztői eszközök szerint összesen 227 kilobájtnyi HTML-t gyártott (Fejlesztői eszközök, HTML fül, jobb gomb a <html> elemen, Copy OuterHTML), míg az enyém 3.

Ez a 14 ikonra levetítve 16 kilobájtnyi kódot jelent egyesével. Miért?

Mérés

Találtam egy bő 600 kilobájtos JS fájlt a gépemen, ennek a feldolgozása (betöltés gyorsítótárból, parse-olás stb.) ugyanebben a böngészőben 480ms. Tehát a Google Drive esetében az 1,3 megabájt JS kódnál egy nagyjából 1 másodpercet tesz ki. Mi történik a többi 15-ben?

Nagyon kíváncsi vagyok a tisztelt kollegák véleményére, magyarázatára, mert minél többet gondolkodom a dolgon, annál kevésbé értem.
 
1

Szerintem túlságosan

hóhér · Feb. 7. (Sze), 02.09
Szerintem túlságosan leegyszerűsíted a dolgot.
A rengeteg JS lehet, hogy felesleges, csak a google dolgozói lusták voltak rongyosra optimalizálni a keretrendszerüket, így egyben lerántja az egészet.
De van egy olyanom, hogy jó részére valóban szükség van a teljes funkcionalitás eléréséhez.
Csillog-villog, mellette még egy komplett fájlkezelőt is ad a böngészőn belül úgy, hogy lehetőleg egyformán lásd böngészőből, android kliensből stb.
3

Egyforma

Hidvégi Gábor · Feb. 7. (Sze), 10.24
Amit csináltam tesztoldalt, egyformán néz ki böngészőben, Android kliensben, és tökéletesen működik még Lynxben is.
5

Lusták :)

Pepita · Feb. 7. (Sze), 11.30
a google dolgozói lusták voltak rongyosra optimalizálni a keretrendszerüket
Enyhén szólva túlzás, hogy lusták lennének, én eddig azt tapasztaltam, hogy elég ügyesen tudnak optimalizálni. :)
2

Szia Gábor! Ismerős a

tisch.david · Feb. 7. (Sze), 09.48
Szia Gábor!

Ismerős a jelenség és szerintem is a hóhér által említett ok áll a háttérben. A jómunkásemberek kivárják, amíg megjelenik az oldal, addig legfeljebb nézik a körbe forgó hullahopp karikát, a JS kódot minden egyes szolgáltatásra ráfaragni meg sok fejlesztői munka lenne. Egyre erősebbek az eszközök, nincs nagy motiváció a fejlesztési időigényes optimalizálásra.

Arról nem is beszélve, hogy biztosan valami saját keretrendszerrel dolgoznak, ami minden problémára ad varázsmegoldást, ennek az ára viszont a feleslegesen nagy JS, az elburjánzó DOM és az erőforrás pazarló algoritmusok.

Üdv:
Dávid
6

Újrahasznosítás

Pepita · Feb. 7. (Sze), 11.48
JS kódot minden egyes szolgáltatásra ráfaragni
Ez ma már egy ezredakkora szolgáltatás-csomagnál is kb lehetetlen lenne, mint a Google. Rendszerszemlélet a varázsszó.

nincs nagy motiváció a fejlesztési időigényes optimalizálásra.
Kb 2 éve változott egy nagyot a Chrome böngésző (jó előre jelezték is): felére csökkent a js motor stack trace-e, vagyis fele akkora "mélységű" függvényhívást és vezérlési szerkezetet lehet azóta használni. (Memóriafelhasználás is nagyot csökkent egyidejűleg.)
Az ok az volt, hogy sok weboldalnál elkezdett "túl sokat fogyasztani" a böngésző, vagyis hamarabb megette a vasat (CPU és / vagy RAM), mint kellett volna.
Érdekes módon a frissítés után az összes Google szolgáltatás zavartalanul működött tovább, így én azt gondolom, hogy nincs baj náluk a motivációval és a ráfordított fejlesztési idővel sem, optimalizálnak amit kell és jól. (Amelyik oldal megfeküdt a stack - csökkentés miatt, azok nagy része jQuery each - nél durrant -> érdemes párszor meggondolni az ilyesfajta "varázsfüggvények" használatát..)

valami saját keretrendszerrel dolgoznak, ... , ennek az ára viszont a feleslegesen nagy JS, az elburjánzó DOM és az erőforrás pazarló algoritmusok.
Ha így lenne, akkor miért is áldoznának rá jóval több pénzt - erőforrást, mint használni egy meglévőt? Pont fordítva van: ha ezt a szolgáltatásmennyiséget bármilyen meglévő és nem a konkrét célra fejlesztett keretrendszerben fejlesztenék le, jóval több js-DOM-stb lenne "az ára".
4

Rossz mérések

Pepita · Feb. 7. (Sze), 11.27
Először is pontosítani kéne, hogy mit szeretnél megmérni és azt hogyan lehet pontosan mérni.

a négymagos Atom processzoros gépemen nagyjából nyolc másodpercnek érződik
Nekem kiürített cache-el, bejelentkezve (így van néhány plusz funkció és menü) pontosan 3.8 sec a DOM felépítése és megjelenítése. A háttérben futnak további xhr reqestek, szóval "nincs vége" a forgalomnak, de maga az oldal ~4 sec alatt használható.

Ez az idő frissítés után sem csökken
Ezt kis tulzással, de alá tudom támasztani: nekem 3.0-ig ment le.

windows task manager kép:
- Ugye nem állítod azt, hogy az egyetlen futó folyamat a böngésző volt? :) Mert innentől a processzor - teljesítményt így mérni kb butaság. Process list-en másodpercenként kiírja az előző sec átlagát %-ban, ez az adott szál teljesítménye, a képen pedig az összes szerepel, kb 30 ... 60 szálé.
- Az első képen mintha Chrome böngésző lenne, ez egyetlen html oldalhoz is 2 szálon fut, amiből csak az egyik "matekol" az adott oldal DOM-jával, js-el, stb. Ezt az egy szálat kéne mérned.
- Nagy valószínűséggel az általad kifogásolt kódot / működést egyetlen szálon, egyetlen mag intézi, emiatt kissé pontatlan mind a négy magot számolni.

Ez 1,3 Gigahertz-cel számolva 42,42 GHz teljesítményt jelent.
Mérnökember létedre összekevered a mértékegységeket... :((( (Teljesítmény Wattban kifejezhető, processzor "teljesítményét" órajel-ciklusban szoktuk. Ez a százalékos dolog libamérleg helyett jó, annyit megmutat, hogy pl az adott mag a csúcshoz képest fele "matekolást" végez.)
Ez a fajta szorzás - osztás a pixelekkel szintén nem egy valid teljesítménymérés, egyébként a chrome-nak van erre saját eszköze, most nem jut eszembe a neve.

Viszont lejön összesen 1,3 megabájtnyi "minifikált" javascript, ami szerintem rengeteg.
Az igaz, hogy nem kevés, de ha már ahhoz viszonyítod, hogy mennyi féle szolgáltatáshoz - feature-höz jön le ugyanez az 1.3 MB, akkor rájössz, hogy mégis tudhatnak valamit a srácok.
Remélem nem bánod, hogy "minifikált", szerintem sokkal jobb, mint kiscsillió darabból (http requestek száma) 10 MB..

Miért szükséges bármilyen javascriptre egy ilyen egyszerű oldal megjelenítéséhez?
A másik téma szálán is jeleztem: nem látod át a koncepció egészét, kiragadsz kis részleteket, emiatt nem tudsz megbékélni a helyzettel.
Nézd meg pl mi történik, amikor gmail-en levélhez csatolsz x fájlt a drive-ról. És ez még egy nagyon egyszerű példa a felhasználói aktivitások közül.
A lényeg az, hogy nagyon sokféle szolgáltatás van, amik mára elég jól össze vannak kötve. Ennek viszont ára is van.

a saját eredményem nem módosult volna érdemben
"Volna, ha az a volna ott nem volna..." - Vagy megmérsz / kipróbálsz valamit, vagy nem. De picit elkeserítelek: ahhoz, hogy ténylegesen meg tudd mérni, tudj ajánlani jobb megoldást, ahhoz az kellene, hogy legalább a felét lefedd a szolgáltatásaiknak ugyanabban a minőségben és ugyanolyan kapcsolatokkal. Akkor tudod megmérni, hogy a Tiéd belefért-e feleannyi kódba, DOM-ba, stb...
Ekkora szolgáltatás-rendszert nem fogsz tudni egyesével külön-külön fejleszteni, illetve sokkal nagyobb lesz az összméret (és teljesítményigény).

Találtam egy bő 600 kilobájtos JS fájlt a gépemen, ennek a feldolgozása (betöltés gyorsítótárból, parse-olás stb.) ugyanebben a böngészőben 480ms. Tehát a Google Drive esetében az 1,3 megabájt JS kódnál egy nagyjából 1 másodpercet tesz ki.
Azt mondtad, programozó vagy, ráadásul úgy tudom, elég jól értesz a javascript nyelvhez.
Ha viszont azt állítod, hogy egy js kódnak a "feldolgozási ideje" pusztán a méretétől függ és egyenes arányban van vele - hát akkor nagyot tévedtem a tudásoddal kapcsolatban.

minél többet gondolkodom a dolgon, annál kevésbé értem
Akkor ne gondolkodj rajta, hanem fogadd el. :-D
Komolyan: esetleg megpróbálhatnál bekerülni a fejlesztőik közé, biztosan sokat tanulnál tőlük, és nem utolsó sorban a legtöbb itt feltett kérdésedre is választ kaphatnál.
Szerintem leginkább azért nem érted, mert kizárólagosan nagyon pici részegységeket vagy csak hajlandó mikroszkóp alá tenni, így eleve figyelmen kívül hagysz egy rakat függőséget.
És itt még nem is érintettük az üzleti érdekeit, a felhasználók elemzését, ami pedig saccra a felét jelenti a cuccnak. ;)
(Viszont a múltkori xy bank témánál ilyen fel sem merült, ezért itt se érzem fontosnak.)
7

Nekem kiürített cache-el,

Hidvégi Gábor · Feb. 7. (Sze), 12.21
Nekem kiürített cache-el, bejelentkezve (így van néhány plusz funkció és menü) pontosan 3.8 sec a DOM felépítése és megjelenítése. A háttérben futnak további xhr reqestek, szóval "nincs vége" a forgalomnak, de maga az oldal ~4 sec alatt használható.
Nálam meg, mint írom, nyolc. Mennyi idő alatt tölt be az általam készített tesztoldal, aminek ugyanaz a funkcionalitása (14 kép, rákattintva letölt)? Milyen i7 vagy Xeon is van a gépedben?

Ugye nem állítod azt, hogy az egyetlen futó folyamat a böngésző volt? :) Mert innentől a processzor - teljesítményt így mérni kb butaság. Process list-en másodpercenként kiírja az előző sec átlagát %-ban, ez az adott szál teljesítménye, a képen pedig az összes szerepel, kb 30 ... 60 szálé
De, bizony, kilőttem mindent, csak a böngésző futott. Láthatod, hogy előtte és utána laposak a görbék. Tehát abban az egy percben semmi mást nem csinált a gép az alapfolyamatain túl, csak újratöltötte a Drive-ot.

Az első képen mintha Chrome böngésző lenne, ez egyetlen html oldalhoz is 2 szálon fut, amiből csak az egyik "matekol" az adott oldal DOM-jával, js-el, stb. Ezt az egy szálat kéne mérned.
- Nagy valószínűséggel az általad kifogásolt kódot / működést egyetlen szálon, egyetlen mag intézi, emiatt kissé pontatlan mind a négy magot számolni.
Miért is csak egy szálat mérjek? A böngésző mind a négy magot dolgoztatja. A többi akkor mit csinál? Zabot hegyez?

Az igaz, hogy nem kevés, de ha már ahhoz viszonyítod, hogy mennyi féle szolgáltatáshoz - feature-höz jön le ugyanez az 1.3 MB, akkor rájössz, hogy mégis tudhatnak valamit a srácok.
Bocsánat, én azokból az egyéb szolgáltatásokból egyet sem használok. Nem csatolok, nem töltök fel, nem csillagozom stb. Akkor miért tölti le?

Remélem nem bánod, hogy "minifikált", szerintem sokkal jobb, mint kiscsillió darabból (http requestek száma) 10 MB..
Ezt mérni kéne.

Ez a fajta szorzás - osztás a pixelekkel szintén nem egy valid teljesítménymérés, egyébként a chrome-nak van erre saját eszköze, most nem jut eszembe a neve.
Teljesen mindegy, hogyan hívjuk, egy processzorra és egy másodpercre levetítve bő 42GHz-nyi processzorteljesítmény szükséges a Google Drive megjelenítéséhez az én gépemen. Miért?

A másik téma szálán is jeleztem: nem látod át a koncepció egészét, kiragadsz kis részleteket, emiatt nem tudsz megbékélni a helyzettel.
Nézd meg pl mi történik, amikor gmail-en levélhez csatolsz x fájlt a drive-ról.
Nem vagyok bejelentkezve, nem tudok csatolni, nem használok gmailt. Szükségszerű, hogy minden, az előbbiekben felsorolt szolgáltatásokhoz szükséges programkód lefusson?

De picit elkeserítelek: ahhoz, hogy ténylegesen meg tudd mérni, tudj ajánlani jobb megoldást, ahhoz az kellene, hogy legalább a felét lefedd a szolgáltatásaiknak ugyanabban a minőségben és ugyanolyan kapcsolatokkal. Akkor tudod megmérni, hogy a Tiéd belefért-e feleannyi kódba, DOM-ba, stb...
Nem, Pepita. Én hoztam egy nagyon egyszerű példát: kijelentkezett felhasználóként megnyitom a Google Drive-ot, amiben van hét mappa és hét fájl. A fájlokra rákattintva azokat a böngészőm letölti. Semmi másra nem volt szükségem.

Ennek a műveletnek az elvégzéséhez a Google Drive-on 8 másodpercig kellett várnom. Elkészítettem egy tesztoldalt, amin ugyanez (nálam) 26ms, és a fájlokra kattintva letölti őket a böngészőm.

Semmi mást nem teszteltem, csak ezt az egyszerű letöltő funkciót. Hogy a Google milyen más funkciókat tesz még bele, az engem nem érdekel.

Az érdekel viszont, hogy mi történik abban a 15 másodpercben, amit nem a JS betöltésével és feldolgozásával tölt a böngésző.

Ha viszont azt állítod, hogy egy js kódnak a "feldolgozási ideje" pusztán a méretétől függ és egyenes arányban van vele - hát akkor nagyot tévedtem a tudásoddal kapcsolatban.
Definiáltam, mi a feldolgozási idő. Ezt a példát azért hoztam, hogy arányosítani lehessen. Absztrakció szükséges hozzá. Anélkül programozni is nehéz.

Szerintem leginkább azért nem érted, mert kizárólagosan nagyon pici részegységeket vagy csak hajlandó mikroszkóp alá tenni, így eleve figyelmen kívül hagysz egy rakat függőséget.
Be nem jelentkezett felhasználóként a Google Drive-ból letölteni tudok, ezért számomra érdektelen, hogy milyen más funkciókat tud még a szoftver. Az viszont érdekel, hogy miért nevezed függőségnek például a gmail csatolást, hisz inkább származék. Miért kell ezt betölteni minden mással, ha nem is tudom használni?
22

Ne már :)

Pepita · Feb. 9. (P), 13.43
Mennyi idő alatt tölt be az általam készített tesztoldal
Valamivel gyorsabb, de minden funkció is működik? (Költői kérdés, pl a többi szolgáltatásra kapásból nem tudok átnavigálni.)
Milyen i7 vagy Xeon is van a gépedben?
Ebben amin mértem i7-6700, 16 GB RAM
Miért is csak egy szálat mérjek? A böngésző mind a négy magot dolgoztatja
Ebben én nem lennék olyan biztos, nekem eddig sosem sikerült az összes magot "odaadni neki". A többi mondjuk a maradék 30-60 szálon van, amit "nem tudsz kilőni". A chrome 2 szálja is nem ritkán egy mag, csak pl Hyper-Threading (ha alkalmas rá a proci).
Bocsánat, én azokból az egyéb szolgáltatásokból egyet sem használok.
Ezzel kb egyedül vagy. Nem ismerem a konkrét statisztikát (gondolom üzleti titok), de biztos vagyok benne, hogy az átlag gugli user legalább 3-5 gugli-szolgáltatást használ rendszeresen. És amikor egyikről a másikra vált, akkor sem szeretne több perces betöltést, hiszen "a gugli oldalán van". Ezt nem vagy hajlandó elfogadni, hogy a túlnyomó többségnek ez így jó.
Ezt mérni kéne.
Akkor mérd. Én azt gondolom, hogy ma egy fejlesztőnek a legalapvetőbb tudásához hozzá tartozik az is, hogy ha ugyanazt a dolgot kevesebb http request-el és kevesebb adatforgalommal meg lehet oldani, akkor az biztosan gyorsabb lesz.
Teljesen mindegy, hogyan hívjuk
Nem, nem mindegy. A Hertz másodpercenkénti rezgésszám (bármié, nem csak elektronikai), a Watt pedig teljesítmény.
Nem vagyok bejelentkezve, nem tudok csatolni, nem használok gmailt. Szükségszerű, hogy minden, az előbbiekben felsorolt szolgáltatásokhoz szükséges programkód lefusson?
Aminek nem kell, az nem fut le. Csak ott van, részben cache technika miatt, részben azért, hogy lefusson, ha kell.
Akár tetszik neked, akár nem. Ne használd egyik szolgáltatásukat sem, ha nem akarod.
Semmi másra nem volt szükségem.
Neked lehet, hogy nem. Rajtad kívül viszont a userek túlnyomó többsége be van jelentkezve és szüksége van másra is. Írj a guglinak, hogy Téged kezeljen megkülönböztetett felhasználóként és soha semmi ne működjön úgy számodra, mint másnak. :)
Ha sikerül, akkor kérlek add meg a csatornát, hogy hogyan kaptál választ, mert néha sokkal fontosabb dolgokban nekem is lenne rá szükségem. :)
Az érdekel viszont, hogy mi történik abban a 15 másodpercben, amit nem a JS betöltésével és feldolgozásával tölt a böngésző.
Valami (gond) mégiscsak a gépeddel lesz, mert nekem telón (régin) se jön ki 6-7 sec-nél többre. Hogy "mi történik" nálad, azt kérdezd tőlük.. :)
Ezt a példát azért hoztam, hogy arányosítani lehessen.
Rossz a példa. Pár száz byte-on is írok neked olyan js kódot, amitől lefekszik a böngésződ. Innentől lényegtelen, hoyg mekkora a fájlméret, a kódminőség ugyanolyan fontos, nem elhagyható szempont.
számomra érdektelen, hogy milyen más funkciókat tud még a szoftver.
Például be tud léptetni, ha szeretnéd. Remélem nem akarod azt mondani, hogy egy egyszerű login után szeretnél extrém sokat várni mindenféle js és css cseréje miatt? Akkor azon háborognál, hogy login után miért olyan sok. Nem akarod elhinni, hogy guglinál külön csapat foglalkozik ezzel folyamatosan, nem kevés fejlesztési idővel. Az a baj, hogy egymagad megközelíteni sem tudod azt a befektetett energiát - de azért váltig állítod, hogy jobbat tudsz.
Mondtam: akkor csináld meg. Nem egy anonym "drive-ot", hanem legalább a felét, amit nyújtanak. Akkor van értelme "mérni" valamit.
miért nevezed függőségnek például a gmail csatolást, hisz inkább származék
Egyik szolgáltatás részben függ(het) a másiktól, de ugyanakkor lehet annak származéka is. Azt gondolom, ez jóval kevésbé kifejezhető binárisan, mint hogy a frekvencia ugyanaz-e, mint a teljesítmény...
Miért kell ezt betölteni minden mással, ha nem is tudom használni?
Nem tudom, hogy pontosan mik és mikor töltődnek be, tippeltem. Például azért (ez is csak 1 tipp), amit már írtam: mert a többség belépve használja, és ha Te is belépsz, ne az tartson percekig.

Remélem így már tisztult kicsit a kép, ha nem, akkor én sajnálattal el fogom engedni a témát.
21

Minimum

Pepita · Feb. 9. (P), 13.42
Elkészítettem egy tesztoldalt, amin ugyanez (nálam) 26ms
Szerintem a mappa linkekre kattintva legalább az adott mappát kéne kilistázni, nem minden kattintásra ugyanazt az egy fájlt letölteni...

Ez a baj, hogy a "tesztoldalad" gyakorlatilag semennyit nem valósít meg a vizsgált funkcionalitásból (a kapcsolt szolgáltatásokon kívül sem).
23

Absztrakció

Hidvégi Gábor · Feb. 9. (P), 15.54
Már írtam korábban, hogy némi absztrakció szükséges az általam leírtak megértéséhez.

Készítettem egy példaoldalt, amin van hét mappa és hét fájl ikonja.

Most próbáld meg elképzelni, hogy a mappákra kattintva egy nagyon hasonló oldal jön be, csak azon mások az ikonok. Az pontosan ugyanilyen gyorsan jelenne meg.

Tehát a lényegen nem változtat, hogy egy vagy száz példaoldalt készítek.

Sikerült?

Ez nagyon analóg azzal, amikor azt írtam, hogy a Google Drive összesen 16 másodpercig dolgoztatja a processzort. Azt is leírtam, hogy az én gépemen nagyjából nyolc másodperc után használható, de ettől függetlenül a Chrome tizenhat másodpercig dolgoztatja a négy processzort.

Ez érthető?

Engem az érdekel - és még nem kaptam rá magyarázatot -, hogy mi történik ez alatt a tizenhat másodperc alatt. Igen, nyolc másodperc alatt használható a Drive, de tizenhatig megy a négy mag.

Ezt te is kipróbálhatod, csak az i7-esen arányosan kisebb számok jönnek ki.

Nekem nem i7-esem van, hanem egy Atom, ezért nagyobbak a számok. Azzal nem tudok mit kezdeni, hogy neked i7-esed van, mert az nem egy átlagos hardver, a legtöbb felhasználónak ennél lassabb van. A mobiltelefonok többsége az Atomos gépemmel nagyjából megegyező sebességű. Ma már az internetet jelentős mértékben mobilról böngészik, ezt ezért tartom fontosnak.

Most mit érzel, miközben ezeket olvasod? Én pontosan ugyanezt éltem át a te soraid abszolválásakor.

---

Ugyanilyen absztrakciós készség szükséges ahhoz, amit a processzorteljesítménynél írtam.

Abból indultam ki, hogy a csatolt képen látszik, a Google Drive betöltésekor négy mag dolgozik tizenhat másodpercig, mindegyik átlagosan 50% teljesítményen. Ha arányosítani szeretnénk, ez, ugye, jó kerekítéssel megfelel annak, mintha két mag ugyanennyi ideig 100%-on dolgozna, vagy egy magra levetítve harminckét másodpercnyi munkának. Mivel a processzor 1,33 Gigahertzes, ezt egy gigahertzre számolva nagyjából azt jelenti, mintha egy egy gigahertzes processzor 42 másodpercig dolgozna száz százalékon, vagy arányosan egy 42 gigahertzes gép egy másodpercig.

Erre írtam, hogy 42 gigahertznyi teljesítmény. Tisztában vagyok, hogy ez egy pongyola megfogalmazás, de aki el tud vonatkoztatni (absztrakció) ettől a pontatlanságtól, az megérti a mondanivalót.

Természetesen bele lehet kötni a mértékegységbe, csak kérdés, hogy van-e értelme, és a "nagy" probléma szempontjából mi a jelentősége.
25

Absztrakció?

Pepita · Feb. 12. (H), 16.06
Ez vajon mi lehet Hidvégi Gábor fogalomtárában? (Remélem most jó "i"-t használtam.)

Most próbáld meg elképzelni, hogy a mappákra kattintva egy nagyon hasonló oldal jön be, csak azon mások az ikonok.
Ennyi erővel azt is mondhatnád, hogy "képzeld el, mintha lefejleszteném az összes guglis feature-t és ugyanilyen gyorsan működik, rájuk vertem 16-szoros sebességet".
Nos, a képzelőerőmmel szerintem nincs semmi gond, de mérnökemberként a szakmámban tényeket és mérési eredményeket szeretek összehasonlítani, nem képzeletbeli dolgokat.

Ez nagyon analóg azzal, amikor azt írtam, hogy a Google Drive összesen 16 másodpercig dolgoztatja a processzort.
Még mindig nem világos, ez hogy sikerült neked 4 magon, ha egy megnyitott lapról beszélünk. Tartok tőle, hogy az egész mérés invalid.

Ezt te is kipróbálhatod, csak az i7-esen arányosan kisebb számok jönnek ki.
Úgy tűnik, bőven aránytalanul kisebb számok jöttek ki. Azért nem mondanám 4.5 x erősebbnek az i7-et az Atomnál.

A mobiltelefonok többsége az Atomos gépemmel nagyjából megegyező sebességű. Ma már az internetet jelentős mértékben mobilról böngészik, ezt ezért tartom fontosnak.

Nos, a teszt kedvéért módosítottam jócskán PC-ről a drive-omon, majd hatalmas teljesítményű telefonomon is megnyitottam, épp 3G-s mobilnetről. Kevesebb, mint 5s volt, minden funkcionalitással együtt.
Azt javaslom, hogy mint a PC-t használók többsége, Te is asztali / laptop géphez illő, 10 évesnél fiatalabb procit használj, mert bármilyen szoftvert / webappot nem úgy kell "telefonra tesztelni", hogy azzal hasonlóan kis teljesítményű asztali PC-vel próbálgatod, egész más oprendszeren, stb.
Ha linkelnél hasonló adatlapot az Atomodról, mint én az i7-ről, akkor könnyebb lenne összehasonlítani.

Most mit érzel, miközben ezeket olvasod?
Azt, hogy nem igazán szeretnéd megérteni, hogy mi és hol a problémád, hanem mindenképpen foggal - körömmel ragaszkodsz a fikázáshoz és hogy Te mennyivel jobban el tudnád végezni többezer ember munkáját.

Ugyanilyen absztrakciós készség szükséges ahhoz, amit a processzorteljesítménynél írtam.

Processzor "teljesítménynél" vegyük inkább alapnak az órajelciklust, mert ebből kiindulva szinte bármelyik processzora +/- 10% eltéréssel ki lehet számolni a tényleges futásidőt másodpercben, amennyiben ismert az órajel(GHz) és a magok száma.
Ott van azért az a 10%, mert kívülről nem tudjuk, hogy hány szálon mehet egyszerre a cucc, de egész jó viszonyszámot ki lehet hozni pl Atom és i7 között.

Másik lehetőségként továbbra is erősen javaslom a Chrome saját task manager-ét. A kedvedért rákerestem, és nincs is szükség semmilyen plugin-re vagy extension-re, csak nyomd meg a SHIFT + ESC billentyűket. :)
Ezután nyisd meg új lapon a drive-ot, és látni fogod az adott lap konkrét "fogyasztását" real time. Itt is %-ban látható a processzor kihasználtsága, de ellentétben a windowsos task managerrel, adott böngészőlap erőforrásigényét látod.
Ha esetleg egy nagy képkockaszámú videót is csinálsz a tesztről, akkor vissza tudod nézni egész pontosan, hogy a kattintástól kezdve mikor mennyi erőforrásigény van.
Plusz lehetőség még (akár egyidőben) a böngésző (development tools) network fülén megnézni, hogy mi mennyi idő alatt töltődött be, ha szerencséd van, DOMContentLoaded időt is láthatsz (bár a drive sok XHR kérést küld periodikusan, így a DOM idő nem biztos, hogy valid.)

A nagy probléma szempontjából annyi a jelentősége a "kötözködésemnek", hogy próbáltalak kicsit pontosabb és ferdítésektől mentes mérés irányába terelni, sajnálattal látom, hogy ez számodra kötözködés... Természetesen bárki képes "pongyolán fogalmazva" a valóságtól nagyon eltérő adatokat produkálni, én feltételeztem, hogy nem ez volt a célod, ezért jeleztem, hogy hol van benne olyan buktató, ami túl nagy tévedésekhez vezet. Ilyen "mérésre" alapozni olyan súlyos ítéleteket, amiket tettél - hát nem túl korrekt szakmailag.

De elnézést kérek, nem kötözködöm többet. :/
8

Érdekes

Endyl · Feb. 7. (Sze), 14.08
Én azt sem értem, hogy ipari termelés esetén miért költenek többmilliós gépekre és az üzemeltetésükre. Én például egy 15-20 ezer forintos kenyérsütővel sokkal olcsóbban el tudok készíteni 1db kenyeret, mintha azt az 1db kenyeret (és semmi mást) az ipari sütödében próbálnám elkészíteni.



Azt sem gondoltam volna soha, hogyha egy szoftver funkcionalitásának az 1%-át implementálom, akkor meg tudom oldani 1%-nyi forráskóddal/fogyasztással/stb.



Az "én ezeket nem használom, miért van benne" mentalitásra: ha bemész mondjuk egy tetszőleges boltba/bevásárlóközpontba/hipermarketbe, ott sem minden a te kényelmedet szolgálja, hanem mondjuk más vásárlókét, a partnerekét, a tulajdonosokét, stb; ezeknek a fenntartása mégis bele van kalkulálva az ott megvásárolható termékek árába.

Szóval legközelebb ha mész egy ilyen helyre vásárolni, légy szíves követelj x% kedvezményt, mert te nem használod az alkalmazotti mosdót/étkezőt, feleannyi világítással is rendesen látnál, nincs szükséged légkondira (mert jól bírod a meleget), nincs szükséged fűtésre (mert van rajtad kabát), nem használod az ingyenes parkolót (mert tömegközlekedsz), stb.



Ha tényleg csak fájlokat akarsz megosztani, akkor miért nem üzemeltetsz/bérelsz egy ftp-szervert, és akkor meg van oldva a problémád; csak azért fizetnél, amit használsz.



Ugyanakkor nyilván meg lehetne oldani ezt máshogy is, de a Google számára úgy látszik az x megabájtos js fájlok kiküldése és a különböző szolgáltatásaik összekötése megéri. Legalábbis te szoktál azzal példálózni, hogy mit szólna a megrendelő, ha szándékosan x%-os többletkiadást vagy bevételkiesést okozna valaki; gondolom ekkora mennyiségű kód a Google felhasználószámánál nem kis forgalmat generál, amin elég sokat lehetne spórolni, ha ennek a nagy része csak passzióból lenne benne az oldalban, mert simán ki lehetne dobni és a fenntartására sem kellene erőforrást fordítani; szóval talán mégsem csak a móka kedvéért van ott az a kód? Főleg egy olyan cégnél, ahol állítólag észreveszik a párszáz ezredmásodperces plusz betöltési idő miatti felhasználócsökkenést?
9

Én például egy 15-20 ezer

Hidvégi Gábor · Feb. 7. (Sze), 14.38
Én például egy 15-20 ezer forintos kenyérsütővel sokkal olcsóbban el tudok készíteni 1db kenyeret, mintha azt az 1db kenyeret (és semmi mást) az ipari sütödében próbálnám elkészíteni.
Tehát ipari méretekben (pl. Google) nem lehet gyors és hatékony szoftvereket készíteni?

Azt sem gondoltam volna soha, hogyha egy szoftver funkcionalitásának az 1%-át implementálom, akkor meg tudom oldani 1%-nyi forráskóddal/fogyasztással/stb.
Miért, mit teszel még bele, ami nem ahhoz az 1%-nyi funkcionalitáshoz tartozik? Díszítősorokat?

Az "én ezeket nem használom, miért van benne" mentalitásra: ha bemész mondjuk egy tetszőleges boltba/bevásárlóközpontba/hipermarketbe, ott sem minden a te kényelmedet szolgálja
Szoftver esetében kötelező a nem használt funkciókat betölteni a memóriába?

Ha tényleg csak fájlokat akarsz megosztani, akkor miért nem üzemeltetsz/bérelsz egy ftp-szervert
Mint Pepitának írtam, némi absztrakció szükséges az általam vázolt probléma megértéséhez.

szóval talán mégsem csak a móka kedvéért van ott az a kód?
Hát akkor miért van ott? Engem ez érdekel. Meg az, hogy mi történik az alatt a tizenhat másodperc alatt.
10

Miért, mit teszel még bele,

Endyl · Feb. 7. (Sze), 15.59
Miért, mit teszel még bele, ami nem ahhoz az 1%-nyi funkcionalitáshoz tartozik? Díszítősorokat?

Ezzel arra céloztam, hogy hiába vered a melledd, hogy mennyivel kevesebb kóddal megvalósítod a google drive-ot, mert nem azt tetted, hanem csak annak egy töredékét (triviális letöltés funkció), így nyilván meg tudod oldani töredék mennyiségű kóddal.

Ahogy Pepita is mondta, majd akkor szólj, ha a drive minden funkcióját (nem csak azt, amit éppen használsz, vagy kedved van hozzá) megvalósítottad. Majd akkor méregethetjük, kinek nagyobb a kilobájtja.

Mint Pepitának írtam, némi absztrakció szükséges az általam vázolt probléma megértéséhez.

Úgy látom itt is szivároghatnak az absztrakciók.

De mint ahogy többen már írták neked, némi absztrakció szükséges a Google szolgáltatásainak megértéséhez.

Hát akkor miért van ott? Engem ez érdekel. Meg az, hogy mi történik az alatt a tizenhat másodperc alatt.

Hadd ne linkeljem az egszerű hibakeresés cikkedben a JS debuggeres részt :) Ha ennél praktikusabb választ vársz, akkor interjúvolj meg egy drive fejlesztőt.



A leginkább az a bosszantó ezekben a témákban, hogy látszólag értelmes, jó szakember létedre, kontextustól függetlenül kiragadsz "problémákat", és csúsztatásokkal teletűzdelve bemutatsz valamit, ami alapján dobálod a sarat másokra, nem figyelve a probléma egészére (lásd: "miért van ez a sok minden a driveban, én csak fájlt akarok letölteni": mert a drive nem csak fájlletöltésről szól, kész). (Bár az tény, hogy most legalább az ostobázás elmaradt :) )



Nyilván azt sem mondom, hogy a Google minden (vagy akár bármelyik) szolgáltatása a mérnöki tervezés és munka csúcsa, amitől jobbat nem lehet alkotni (amikor először kipróbáltam a Chrome-ot, a gmail-től, youtube-tól rendszeresen összeomlott :) ). Ott is nyilván ugyanolyan emberek dolgoznak, akik ugyanúgy hibáznak is. Viszont mind a lehurrogás, mind pedig a "majmoljuk a Google-t/nagyokat" trend szempontjából érdemes szem előtt tartani, hogy ekkora cégeknél már az infrastruktúrájuk mérete miatt is könnyen lehet, hogy más prioritásokkal állnak hozzá akár egy egyszerű letöltéshez is. Nem mondom, hogy ez a hozzáállás a jó, vagy a legjobb, vagy hogy bármilyen (kisebb) cég számára követendő, de valamennyire érthető (elvégre még nem ment csődbe a Google, tehát nekik megérheti így csinálni).
11

Ezzel arra céloztam, hogy

Hidvégi Gábor · Feb. 7. (Sze), 16.34
Ezzel arra céloztam, hogy hiába vered a melledd, hogy mennyivel kevesebb kóddal megvalósítod a google drive-ot, mert nem azt tetted, hanem csak annak egy töredékét (triviális letöltés funkció), így nyilván meg tudod oldani töredék mennyiségű kóddal.

Ahogy Pepita is mondta, majd akkor szólj, ha a drive minden funkcióját (nem csak azt, amit éppen használsz, vagy kedved van hozzá) megvalósítottad. Majd akkor méregethetjük, kinek nagyobb a kilobájtja.
De miért kéne egy egyszerű letöltéshez megvalósítani a Google Drive minden funkcióját? Hisz bejelentkezés nélkül nincs is hozzájuk jogosultságom. Pl. nincs gmail-em, akkor miért kell a gmail-es részt kiküldeni nekem? Hisz egy egy addícionális dolog a fájlmenedzsment részhez képest.

»Hát akkor miért van ott? Engem ez érdekel. Meg az, hogy mi történik az alatt a tizenhat másodperc alatt.«

Hadd ne linkeljem az egszerű hibakeresés cikkedben a JS debuggeres részt :) Ha ennél praktikusabb választ vársz, akkor interjúvolj meg egy drive fejlesztőt.
Tehát fogalmad sincs. Nem is zavar? Miért nem?

---

Elfelejtettél válaszolni a következő kérdésemre: Szoftver esetében kötelező a nem használt funkciókat betölteni a memóriába?
12

Fogalmam sincs, hogy milyen

Endyl · Feb. 7. (Sze), 20.22
Fogalmam sincs, hogy milyen üzleti, mérnöki, fejlesztői döntések eredménye az, hogy az egész appot betöltik "vendég" felhasználónak is, mivel nem veszek részt a drive fejlesztésében. Nyilván meg lehetne oldani azt is, hogy bizonyos esetekben bizonyos részeket ne töltsenek be, de valamiért nem így döntöttek. Egy adat és statisztikamániás cégnél csak feltételezni tudom, hogy ez számukra nem egy rossz döntés. De amíg egy bennfentes nem nyilatkozik, csak találgatni tudunk.

Ugyanakkor nem zavar, mert még sohasem okozott problémát, mert egyrészt ritkán használom a drive-ot, másrészt amikor meg igen, akkor sem éreztem kifejezetten lassúnak.
13

Világos

Hidvégi Gábor · Feb. 8. (Cs), 13.21
Jó, tehát nincs ötleted, miért ilyen lassú.

Gondolom, számodra ezek alapján nem egyértelmű, hogy adatokat csak úgy lehet-e gyűjteni felhasználókról, hogy az ember letölti mellé a fél világot. Mondjuk az tény, hogy így is megoldható.
14

Igazából arra nincs ötletem,

Endyl · Feb. 8. (Cs), 15.03
Igazából arra nincs ötletem, hogy te mit vársz tőlünk. Azt szeretnéd, hogy deobfuszkáljuk neked a drive kódját és elmondjuk, hogy pontosan miket csinál? Vagy valaki az idejárók közül drive fejlesztő és az ő válaszára vársz? Esetleg szeretnél közösen összeesküvéselméletek gyártani, hogy a Googlenél igazából a legalkalmatlanabb fejlesztőket foglalkoztatják? Vagy szeretnél alternatívát javasolni/készíteni a Google szolgáltatásaira? Netalán arra van ötleted, hogy hogyan lehetne eljuttatni a tömegekhez a féltve őrzött egy igaz fejlesztői módszeredet?

Mi a célja ezeknek a szálaknak? (a sárdobáláson kívül)

Egyébként honnan tudnánk annál többet mondani, mint amilyen adatokhoz te is hozzáférsz a különböző fejlesztői eszközök segítségével?

Gondolom, számodra ezek alapján nem egyértelmű, hogy adatokat csak úgy lehet-e gyűjteni felhasználókról, hogy az ember letölti mellé a fél világot. Mondjuk az tény, hogy így is megoldható.

Itt nem értem, hogy hogyan jutottál erre a következtetésre, vagy hogy egyáltalán mit akarsz ezzel mondani/kérdezni.
15

Sárdobálás

Hidvégi Gábor · Feb. 8. (Cs), 16.11
A sárdobálás nagyon kemény szó, és igazán kíváncsi lennék, miért írtad. Azt jelenti, hogy valaki a másikra - jó okkal vagy alaptalanul - rosszakat mond, a másikat bemocskolja.

Vettem a fáradságot, és újraolvastam mindent, amit ezen az oldalon írtam, javaslom neked is!

A kijelentő mondataimban megosztottam az általam mért adatokat. Semmit és senkit nem minősítettem, nem vontam le következtetéseket. A kijelentő mondatok után kérdéseket tettem fel.

Úgyhogy megkérlek, tisztázd, hol van itt a sárdobálás, mert szerintem minden alap nélkül járatsz most le engem.

A többi kérdésedre a választ akkor kapod meg, ha ezt megtetted.
16

A sárdobálás előtti kérdésben

Endyl · Feb. 8. (Cs), 16.50
A sárdobálás előtti kérdésben többes szám volt, mivel van példa arra, hogy hasonló kérdéseket feszegető témákban leszólsz olyan embereket, akik nem a te szájízed szerint fejlesztenek (sokszor ha konkrét leszólást nem is írsz, a stílusból mégis az jön le számomra). Azt is írtam egy fentebbi megjegyzésben, hogy konkrétan ebben a témában ez nem történt meg.

Elnézést, ha úgy jött volna le, de nem célom a lejáratásod (írtam is, hogy én igazából jó szakembernek tartalak az itteni írásaid alapján; sokmindenben egyet is értek veled, de a hozzáállásod sok esetben számomra érthetetlen, mivel a konstruktív aspektusa nem jön át a dolgoknak).

Szóval, ahogy te nem érted a Google-t, én úgy nem értem, hogy miért ölsz ekkora energiát ezeknek a témáknak a feszegetésébe, amikor a konkluzió jobbára csak annyi, hogy valamit valaki nem a legszerencsésebben oldott meg (amennyire külső szemlélőként ezt meg lehet ítélni), te viszont töredék mennyiségű kóddal/komplexitással/buggal/stb. meg tudnád oldani ugyanazt.
18

Energia

Hidvégi Gábor · Feb. 8. (Cs), 22.03
Amit most leírok, abból azt hiszel el, amit akarsz, de talán érthetővé válhat az attitűdöm. Az érvelésedet követve azért fontosnak tartanám hozzátenni, hogy nyilvánvalóan én sem fogom jó alap nélkül hülyévé tenni magam mások előtt.

Lassan tizenkettedik éve, hogy egy integrált vállalatirányítási rendszert fejlesztünk, amit jelenleg pár cég használ, és ha minden jól megy, ősszel lépünk piacra vele. Ebben lehet számlázni, raktárkészletet kezelni, kapcsolatot tartani, hozzá lehet férni a levelezéshez, lehet fájlokat fel- és letölteni, ezeket és az egyéb dokumentumokat egymáshoz csatolni, nyomtatni, kimutatásokat készíteni, az adatokat exportálni különböző formátumokban, végtelen scroll stb.

Ha jól belegondolunk, ez elég jól lefedi a Google Drive - Gmail szolgáltatásokat.

Csatolom a legbonyolultabb űrlapunk képét, amin többek között a számlákat lehet kezelni. Igen, csúnya, de mentségünkre legyen mondva, hogy csak két hete csatlakozott hozzánk olyan ember, akivel a kinézetet és a használhatóságát meg tudjuk csiszolni.



Mint látható, némileg több látható elem van rajta, mint a Google Drive-én, bár a DOM-ban ez kevesebb, egészen pontosan 800. Ennek a lerenderelése az adatok betöltése után 530ms körül van, és ebben minden benne van (a fenti Atom processzoros PC-n). Ha mellé teszem, hogy a kliensprogramunk 59 (ötvenkilenc) kilobájt, akkor az már kezdi az "ezt úgysem hiszem" szintet megütni.

Az ember nem lehet mindig tökéletesen elégedett, ezért már dolgozom a következő verzióján. Most mértem le, ugyanennek az űrlapnak a renderelése 123ms.

Ez most egy belső fejlesztés, de neked szívesen megmutatom, még a forráskódot is, mert te rendes ember vagy.

Mi a célom a felhozott témákkal?

Az egyik az, hogy kibillentsem a kollegákat a megszokott keréknyomból. Ez a korábbi két írásomban talán kicsit túl jól sikerült, a kognitív disszonancia elég erős lehetett. Talán emiatt is lett ez az írásom jóval visszafogottabb.

A másik cél, és ezért teszek fel kérdéseket, hogy gondolkodásra késztessem a társaságot. Bár már leírtam az évek során minden tudásom, de úgy hiszem, hogy akkor tud fejlődni az ember, ha saját maga elkezd utánajárni, átgondolni, kipróbálni, azaz tapasztalatot szerezni.
20

Nekem is!

Pepita · Feb. 9. (P), 13.28
neked szívesen megmutatom, még a forráskódot is, mert te rendes ember vagy.
Nekem is lécci-lécci-lécci, de én gazfickó vagyok! :-D

Hatalmas különbség van a Ti és a Google rendszerei között: a Ti célközönségetek egy eléggé szűk üzleti kör, míg Google kb mindenkire céloz, a legszegényebb (de internetet használó) egyéntől a legnagyobb cégekig. Ennél fogva a nyújtott szolgáltatások is rendkívül különböznek.

Ettől függetlenül szívesen tanulnék a Ti példáitokon is, abban biztos vagyok, hogy elég rendhagyó.

már leírtam az évek során minden tudásom
Ez baj, a jó pap is holtig tanul, csak akkor tudsz leírni mindent, ha közben nem fejlődsz..
24

Nem feltétlenül tűnik

Endyl · Feb. 9. (P), 20.46
Nem feltétlenül tűnik hihetetlennek.

Ez most egy belső fejlesztés, de neked szívesen megmutatom, még a forráskódot is, mert te rendes ember vagy.

Megtisztelő a bizalom, de hacsak nem ragaszkodsz hozzá, nem szívesen ütöm az orrom más üzleti titkába :) Valamikor azt írtad, egyszer majd publikálsz dolgokat a módszeredről, szerintem ráérek megvárni azt.



Ezekrő a témákról valahogy mindig ez jut eszembe (az lényegtelen, hogy ki melyik szerepben van éppen, általában oda-vissza változik): You're not going to believe what I'm about to tell you
19

13-ra:

Pepita · Feb. 9. (P), 13.16
Jó, tehát nincs ötleted, miért ilyen lassú.

vs
akkor sem éreztem kifejezetten lassúnak.


Gábor, itt Endyl szájába próbáltál már adni olyan véleményt, ami ellenkezik az övével.
Ez ne fair, viszont azt mutatja (számomra), hogy nem megérteni szeretnéd a dolgot, nem tanulni belőle, hanem egyszerűen csak ellenkezni. Ráadásul olyan dolgokban, amikre mi is csak tippelgetünk, mert egyikünk sem drive- vagy gugli fejlesztő.

Azt hiszem nekem ezen a ponton ment el a kedvem ettől a témától. :(
17

Szerintem a titok nyitja,

inf3rno · Feb. 8. (Cs), 21.52
Szerintem a titok nyitja, hogy mi van abban az 1MB-nyi minify-olt js kódban. Ami biztos, hogy tutira nem én leszek az, aki bele fog túrni, mert erre most nagyon nincs kedvem, időm.