Tento článek mi připomněl historky, co nám říkali ve škole staří praktici. Rekonstruovanou soupravu metra řídili (a možná ještě řídí) procesory 80196 (bráška 80186 s nějakými periferiemi navíc). Takže bylo potřeba normalizovat veličiny do 8 bitů. V případě rychlosti se transformoval rozsah čísel 0-255 na rozsah 0-81.92 km/h (maximálka je 80, tedy je to akorát). Jeden dílek pak odpovídal 1/32 což je 0.03125 km/h, tedy rozlišení víc než dostatečné. Ale teď bylo potřeba udělat drážní zkoušky, kde se musí vozidlo zkoušet při +20% tj. nějakých 96 km/h, což je mimo rozsah a pro ty zkoušky prý musel být software upravený.Podobnou historku nám vyprávěl jiný učitel u vlaků dnes známých jako city elefant. Tam šlo pro změnu o teplotu, kterou do 8 bitů ukládali jako -128...+128°C (tedy klasický shortint). Na zkušebně to fungovalo výborně, ale přišlo léto a strojvůdci si prý začli stězovat, že jim ta mašina netáhne (tak to říkal ten učitel, z jiných zdrojů jsem slyšel horší popis situace, typu že hoří). Ukázalo se, že se tak stává, když teplota dosáhne 128 a víc stupňů, které model vidí jako -128 a víc a výpočet pak pochopitelně selhává. Přitom třída izolace dovolovala 155°C. Už si nepamatuju řešení, ale předpokládám, že se posunula nula tak, aby rozsah odpovídal reálným možnostem (je logické, že pod -100 neni ani na sibiři).Posledních několik let pracuju s procesory v plovoucí řádové čárce (výpočty v plovoucí čárce probíhají stejně rychle jako v pevné), takže mám o starost s normalizací a převodem na počítačové jednotky méně. Ale ona vzpomínka na doby, kdy člověk musel řešit rozsah a rozlišení (třeba jestli stačí rozlišení 0.05Hz pro kmitočet sítě?) na mě dýchla i když dřevní doby (typu SAPI) osobně nepamatuju. Zrovna nedávno někdo vzpomínal na SAPI a že ho arduino strčí ve většině parametrů do kapsy.
Šlo by to ještě stlačit dolů, v objemu přenášených dat. Je dobré si uvědomit, že data, která se přenáší (teplota, vlhkost,...) jsou spojité funkce v čase, s relativně pomalou změnou, tj. stačí přenášet jen informaci o relativní změně.Při troše vůle a dosti rychlém vzorkování všech 4 veličin, by to tudíž šlo stlačit i na 1 Byte.
Názor byl 1× upraven, naposled 31. 1. 2017 22:05
Mnouhem lepší, než používat pole a do něj to kopírovat, je používat __packed strukturu, např.typedef struct __attribute__((packed, aligned(4))) { float teplota;uint8_t vlhkost;...}MereniJe to na jednom místě a v rámci celého zpracování se dá jen předávat pointer na ni. Také existuje 16b half precision float... ale na malém MCU je lepší se floatům zcela vyhnout, knihovny sežerou spoustu paměti...
Mě se ten článek moc líbil, ale měl bych jednu připomínku. Před tím, než se dělají takové optimalizace, které žerou čas a snižují čitelnost dat normálním člověkem je dobře se zastavit, vylézt na nejbližší strom a podívat se na to s větším rozhledem. Ja se přiznávám, že se v síťových komunikacích příliš nevyznám, ale myslím, ze tady ke každému odeslanému balíčku nutno připočíst TCP/IP header a IPV4/6 header. To je 40-60 bajtů. Nevím, co si ještě navíc přidá HTTP/HTTPS, pravděpodobně ještě víc. Takže jestli jde vlastní informace jako 11 bajtů nebo 8 nehraje roli. Není to myšleno jako kritika (článek je přece příklad, kde je důležitější stravitelnost informace), ale jako poznámku navíc...
Většina těch IOT rádií je jednoduchá, žádné TCP/IP.
Tam to má jistě větší smysl. Já jsem vycházel z toho, co v článku uvádí autor jako příklad: externí a interní meteorologickou stanici s Wi-Fi.
Tak mi na mysl vytanula poučka: Musíš-li použít assembler, máš ve skutečnosti slabý hardware.
Asm mi přišel strašně cool na didaktiku - dalo se tím dosáhnout neskutečných věcí fungujících neskutečnou rychlostí ... ve srovnání s basicem. Na moderních počítačích mi asm přijde jako nesmysl - dokonce jsem četl, že kompilátory produkují tak dobrý kód, že jej jen málokterý programátor dokáže na úrovni strojového kódu překonat. Teď jsem si zrovna pro svoji překladatelskou práci napsal pár prográmků v C#. Funguje to k mé naprosté spokojenosti, napsal jsem to za pár dnů (kdybych měl praxi, tak za pár hodin... musím hledat kdejakou ptákovinu). V asm bych to šmudlal týdny.
Assembler je dost nešikovný kvůli produktivitě a nepřenositelnosti. Teď sis napsal program pro PC, zítra ho budeš chtít přepsat pro telefon. Kód v C# nebo C++ apod můžeš pravděpodobně bez úprav překopírovat do svého mobilního projektu (aspoň jeho části), ale Assembler z Intelu na ARM přenést nelze. Ani ň. Dnešní kompilátory umí kód dobře optimalizovat a využívat vlastnosti CPU jako je vektorizace, ale úplně perfektní kód ne generují. Navíc binární kód z těch vyšších jazyků bývá dost velký. A některé ani nevytváří strojový kód, ale tzv. Bitcode. Např. C# a Java.
Sorry, bytecode. Bitcode generuje Swift a je to něco jiného.https://en.wikipedia.org/wiki/Bytecode... https://lowlevelbits.org/bitcode-demystified/...
V tom pripade bych potreboval tip na nejaky uC o velikosti pouzdra Soic 8 ktery pobezi na 5V/16Mhz s internim oscilatorem, bude mit ADC prevodnik (aspon jeden) a bude mit vic pameti nez AtTiny85. Kdyz je situace ze musim setrit kazdym gramem/milimetrem proto abych dostal zarizeni do copteru/letadla tak se hodi i bitove operace 😀
ESP8266? Samotný MC má tuším 4x4 mm, ale budete potřebovat 3.3VPak je zde ještě možnost ESP32. Rozměry stejné, parametry úplně někde jinde.
Kapacitu pocitame na intalace Dooma, rozlohu na fotbalova hriste a nesmime zapomenou na silu 162 kavovaru. At zije SI soustava.
To víte, lidi si to líp představí v snadno představitelných "jednotkách" 😃
Drobná narážka na to, že při reloadu stránky živě a stažení Dooma se přenese zhruba stejné množství dat (~2.4MB)
Optimalizovat program tak, aby využíval jen nezbytně nutné množství RAM a HDD.... a mít celý projekt třeba dražší o stovky tisíc či dokonce miliony korun kvůli vynaloženému času programátorů... nebo si přikoupit moduly RAM za pár stovek či tisícovek korun?
První je správně. Jak ale podotýkáš, jde to i způsobem, že to píšeš jako prase a pak dokupuješ RAM... jenže pak se ti klidně na produkčním systému může stát, že ti taková aplikace žere stovky GB RAM a padá, protože jí má stále málo, právě díky tomu jak je prasácky napsaná, plná memory leaků apod...U aplikace typu "malování" to nikdo řešit nebude, u aplikací např. pro sklady/logistiku, kde každá minuta výpadku je klidně několik milionů peněz ztráta, to už asi jen tak neprojde.
EET... 😁Jinak já myslím, že on to zas tak extrémně nemyslel. Prostě až takovéto optimalizace na urovni bitů-bajtů nemá ani moc smysl u nějakých mamutích projektů. Ale to neznamená, že by měli vývojáři psát jako prasata. Třeba raději déle rozmyslet návrh struktury programu než jít hned zbrkle kódit, nebo optimalizace dotazů do databáze apod.
Systémy státní správy bohužel spadají v naprosté většině do kategorie "od prasat", tam se na nějakou stabilitu a rychlost nehraje. Když se to vysere, tak ztráty zatáhne daňový poplatník.
Tak je potřeba najít nějakou rovnováhu. Některé věci se nedají škálovat do nekonečna. Twitter takto škáloval až už bylo serverů neúnosně mnoho. Pak musel přepsat backend z Ruby do Scaly.http://highscalability.com/scaling-twitter-making-tw... ... Asi se dá namítnout, ze Twitter je extrém, ale platí to i v malém měřítku. Můžu rozšířit paměť, přidat CPU, ale těžko něco udělám s I/O (ať už mezi pamětí a CPU, nebo na Internetu, kde nezáleží jen na mém připojení...
Při používání jquery mi tenhle článek přišel vhod k otevření očí 😀
Největší chybou při programování Atmelů je používat pohyblivou čárku. To se musí přilinkovat knihovna math, která zabere spoustu paměti a program běží dlouho. Pokud ta čidla nevysílají ve float formátu, ale např. bitově, je v tomto případě mnohem jednodušší pracovat jen s integrem 8 nebo 16 bitů. Výpočty jsou mnohem rychlejší a desetinná tečka se přidá až na zobrazení. Vím o čem píšu. Dělali jsem systém, který měřil asi 20 hodnot a tři veličiny reguloval (PID) a celé jsme to udělali v celočíselných hodnotách.
koukal jsem na porad o programovani a podle vseho nejvetsi machri jsou v NASA(druzice a autonomni vozitka). Omezeny prisun energie + zareni (minimalizace vseho elektro a stineni) + predpokladana zivotnost (na druzicich mnoho let) + spolehlivost (nemoznost servisniho zasahu).Uzasna optimalizace na praci s fotkama, komunikaci proste vsem. Pro velkou vetsinu ostatnich aplikaci je to desnej overkill ale....
Mě nejvíc fascinuje kombinace baterie + hardware + software v sondě Voyager. Po čtyřiceti letech provozu a daleko od naší sluneční soustavy, v téměř absolutní nule a bez slunečního záření pořád přijímá příkazy a odesílá informace. Klobouk dolů.
noo jeste to zareni, baterie je nuklearni.je neuveritelny s cim vsim pocitaji.
Za nejzajímavější považuju, kolik lze popsat textu o tak samozřejmých věcech 🙂
Jo, vás jsem zaregistroval jako takzvanou samozvanou autoritu i v článcích od P. Tronnera, zejména u počítačů Z80 kompatibilních. Působíte na mě dost arogantně.
F29 Retaliator - cca 100 kBNa javascript používám Yesscript do Firefoxu (blacklist) - oblíbené stránky, které fungují i bez JS to výrazně urychlí
Jej, nostalgie - a ta hra po seriovem kabelu proti kamaradovi... :)
JJ, a marná snaha o přistání ...nechápu jak všechnu tu grafiku dokázali nacpat do těch 100 kB - dneska by se do toho nevešlo ani úvodní logo ...
Zrovna vcera jsem resil jak neco nacpat do AtTiny85. Po odecteni bootloaderu je k disposici 6kB flash a pro beh pak 512b SRAM. To pak clovek sahne po struct s urcenim bitu pro hodnoty nebo eliminaci float velmi rad. Protoze proste nic jineho nezbude. Pokud clovek nepouzije float tak usetri cca 2kB vysledne binarky a to uz je znat.
I v dnešní době se dělají extrémně optimalizované díla.V tomhle 64kB demu máte film s hudbou od mikrosvěta po makrosvět.Do 64 kilobajtů dat se dá toho narvat opravdu hodně.https://www.youtube.com/watch
Kdo dal minus ani nezna demo scenu. Tohle je taky 64kb (napsano v roce 2000): https://www.youtube.com/watch...
Presne, to bola doba optimalizacii. Kde kazdy bajt mal svoj zmysel a opodstatnenie. Dnes na to nie su prostiedky a ani cas. Radsej investovat do vacsej ram, disku, cpu ako do ludi a casu, ktory by bol na to potrebny vyladit do takejto podoby. Kym by sa to finalizovalo, konkurencia by bola uplne kdesi inde a produkt by castokrat nenasiel uz uplatnenie (sad story)🙁.Inak pani, kde to zijete ze 64kB intra😀Dnes uz ficia 4kB intra a to je pocin (zdrojak mensi ako Vasa ikona na ploche)Vytaz 2016 ;)https://goo.gl/e5Z1Rn... Inak boli i stranky, ktore sa tomuto venovali no zanikli. Priklad za vsetko. Riesenie v sutazi na sudoku zadanie ... 67 byte! Potom sa toho este ktosi chytil a sup to na 62 byte !B4 3F 8B D5 CD 21 91 43 88 02 4E 78 F7 B8 31 40 80 3A 2E 75 F5 8B F9 4F 60 78 ED 38 03 75 11 97 D4 13 6B C0 0B 96 43 7B F7 33 C6 A9 C0 E0 7E 02 F6 E4 61 70 E2 C6 02 2E 3C 39 74 F6 EB D1Jednotlive kola a zadania (vratane sudoku) https://goo.gl/OGUQ1T... 😉
No ono vse souvisi se vsim. Jsem z generace ktera zacinala na 8mi bitech a programovani v assembleru ( nebo primo ve strojaku ) bylo jaxi normalni. Nevim proc, uz 20let jsem to nepotreboval ale porad si pamatuji opcode z CPU6502 🙂.No a tak jak se postupem casu na bity nabalily MB/GB/TB tak se na programovani nabalila skupinka "projektaku, analytiku, architektu, lead testeru" ... a vysledek 🙂 to znate asi kazdy sam ... Asi patri k nejake programatorske cti vytvorit kod "ktery proste funguje" a nesezere 200MB na totalni banalitu alespon pro nektere ...
Jo, jenže naprogramovat v asm jednoduchý systém rozbalovacích menu na didaktika m mi zabralo několik dnů - teď je to v ms vizuálku záležitost na pár kliknutí.
Kuba moc na zive nezapada, co?
Že zrovna reklamní farma s názvem Živě.cz filozofuje o tom, proč jsou stránky velké...
"Pojďme si připomenout, jak přemýšleli všichni vývojáři kdysi dávno""..všichni kodéři maximálně nízkoúrovňoví"Programatori pracuji i s binarnimi daty. Koderi pouzivaji vyhradne textova data (CSV, JSON atd). Koder, ktery objevi existenci binarnich dat a manipulace s nimi o tom napise clanek. "Heuréka, zaplnili jsme celý bajt"Uvahou dojde k zaveru, ze to patri k minulosti.Technika redukce dat az do binarni urovne je platna a pouzivana neustale.Pouzivaji ji vyrobci HW, Embeded zarizeni a na to nabaleneho SW atp. Staci si vsimnout jak jsou ruzne ulozeny informace k zarizenim "chipset, sbernice, CPU, GPU atd., zaznamy v reg. windows. ruzne transportni protokoly na fyzickych vrstvach atd". Hodi se pri reseni ruznych problemu s nedostatkem pameti => rychlosti.( Bitove operace patri k tem nejrychlejsim-viz. mozne uziti bit.posunu pro nasobeni pri optimalizaci)Co se tyka usetreni el.energie pri posilani (Kazda komunikace ma svou rezii). Obecne je asi nejlepe poslat co nejvice dat a to nejmenekrat.Analogie s postou - zaplatim mene za jeden velky balik nez za X malych.
Názor byl 5× upraven, naposled 30. 1. 2017 03:18
V tom článku bych řekl, že dokazuje, že to minulosti nepatří.Jinak mě fascinuje tohle rozdělování na kodery, programatory a já nevim co. Nepoužívám binární data, nejsem programátor... Tak to slyším /čtu prvně...Je na to aspoň nějaká mezinárodně ustanovená definice, nebo je to jen vycucaný z prstu?Já mám jinou definici.Pro mě třeba je kodér ten, který nenavrhuje strukturu/architekturu programu, ale jen dostane zadání a nabuší/nakódí dané zadání, přičemž může při tom klidně používat i ty binární data.😉
Já to vidím tak, ze kodér je jednoznačně lepší. Kodér je v telefonu na generálním štábu zatímco programátor je v pračce.
Jen malá připomínka ohledně "nejlépe poslat co nejvíce dat a to nejméněkrát" - to nemusí platit vždy protože se zvyšující se délkou přenosu roste riziko, že bude přenost zarušen nějakým dalším signálem a bude se muset opakovat.Pokud byste takto sbíral a sbíral a sbíral, a pak chtěl naráz vysílat třeba minutu v kuse, je dost pravděpodobné, že byste data nikdy neodeslal protože by se pokaždé vyskytl nějaký kraťoučký zádrhel a musel byste začít znovu. Proto je třeba najít vhodný poměr mezi velikostí a rizikem rušení, který není možné obecně stanovit (v silně zarušeném prostředí logicky budou třeba kratší zprávy než uprostřed divočiny bez rušení)
Myslím že je to zajímavá retrospektiva do hlubuin programování a dob kdy webová stránka s 200kb+ byla považována za šlendrián a dob vytáčeného připojení od Českého Telekomu 😀 .Líbily se mi i hrátky s dvojkovou soustavou, ovšem myslím že by to šlo i v desítkové a poměrně snadno.Teplotu převedeme na celé číslo jak bylo napsáno v článku a k tomito číslu přičteme konstantu: 0,25° - 0,49° = 64 ; 0,5° - 0,74° = 128 ; 0,75° - 0,99° = 192tedy: 35,36°C ==> 35 + 20 = 55 + 64 = 119 a toto číslo odešleme. Hotovo.Zpětně je to trošku složitější, ale s podmínkou pokud se číslo nachízí v intervalu pak odečti 63,75 si bohatě vystačíme.RC
Samozřejmě jsem měl namysli "odečti 83,75" jen rychleji klikám než čtu 😝 .
Správně je, že nejdřív se odčítá těch 63.75 dokud se to nedostane do intervalu a nakonec -20.No a jak sám vidíš, desítkový zápis je v tomto případě mnohem složitější...
Nemohu souhlasit, v desítkové soustavě se mi to jeví snáze pochopitelné pro laika než hrátky s binárními čísly.Myšlenka pro zpětné dekódování byla taková že:pokud je číslo v intervalu 64-127 pak od něj odečtu 83,75 = změřená teplotapokud je číslo v intervalu 128-191 pak od něj odečtu 147,5 = změřená teplota pokud je číslo v intervalu 192-255 pak od něj odečtu 211,25 = změřená teplotaMěl jsem za to, že je to dostatečně pochopitelné pokud uvedu pouze první případ..
No jo, jenže v tom tvém příkladě si s binárními čísly hraješ taky, jen to navíc ještě převádíš do desítkové, takže pro laika to vypadá jako hausnumera. Aby to pochopil, tak mu to stejně musíš všechno vysvětlit. Jiná věc by byla, kdyby třeba teplota byla <50 a přičítaly by se násobky 50, pak je to echt desítkové a jasné.Tvoje verze je oproti binární(temp << 2) |(int)(fract *4)a zpátkytemp / 4.0opravdu neskutečně složitá.
Hmm je to asi o úhlu pohledu, mně je to jasné na první pohled a nepřipadne mi to složité, vše co jsem popsal v desítkové se vlastně udělá v binární - na straně čidla, dokonce jsem eliminoval krok, kdy autor posunuje výsledek přepočtu celé hodnoty teploty o dvě pole doleva. Já prostě jenom přičítám sedmý nebo osmý bit a nebo oba. Kdežto autor stejně pracoval s prvními dvěmi bity... Vlastně místo abych násobil 4 "|(int)(fract *4)", tak násobím 256 a přičítám k celočíselné hodnotě teploty bez posuvu.Popsat dekódování na straně přijímače podmínkami mi přišlo nejsrozumitelnější, přecijenom ne každý holduje počtům ve dvojkové soustavě.Každopádně netvrdím, že moje řešení je nejlepší ale jako alternativa pro pochopení možní poslouží.
A ještě se mi ztratil "interval 64 - 127" :-/ ..
Podobny triky jsem pouzival pri programovani - u cca nekolika desitek milionu ulozenych hodnot v RAM uz se dalo poznat poznat kdyz se velikost stahla o par bytu.Nicmene v tomhle pripade nechapu. Nebude velikost datove casti packetu pri prenosu tak jako tak vetsi nez velikost zpravy pred redukci? Aby nahodou ve snaze usetri energii pri prenosu se nespotrebovala na prenos ta sama energie, ale zato se spotrebovalo vic energie v procesorovych cyklech na orezavani cisel a bitove posuny. 😃
Mno v podstatě je myšlenka správná. Ale v tomto případě se zpracování může protáhnout o pár ms. Ale rozhodně to nemá takový odběr jako samotný přenos, který může být (podle použité metody přenosu) energeticky náročnější až o několik řádů. Mno a to se užna výdrží pozná.
JavaScriptový framework se stahuje typicky jen jednou, pak už je v cache prohlížeče (na disku). Ovšem grafika místo zabírá (obrázky, reklamy, pozadí). Když tam je JPEG, pak to může být 10x až 20x zkomprimováno, takže ze 4MB je rázem 80MB nekomprimovaných dat. A když se to vyrenderuje do webové stránky (tj. do rolovatelné bitmapy), tak to máme (s bitmapama textu) klidně 200 MB. A proto jsou ty prohlížeče tak nenažraný. A proto se s tím nic moc nedá dělat (kromě blokování reklamy).
chceš tím snad říct, že když se lajnou přenášej JPG, tak pro zobrazování v panelu brouseru se to překódovává do velkýho BMP? není to kravinismus???když mám nějakou fotku v JPG na disku a zobrazím si ji v systémovým prohlížeči obrázků, tak se pro to zobrazení taky přepočítává do BMP? že nepřepočítává? tak proč se stejně nechová brouser?
On jaksi monitor neumí jpg zobrazit, potřebuje pixely hezky jeden po druhym, takže něco v kompu to musí rozbalit do bitmapy, ať už to zobrazuje browser nebo cokoli jinýho.
Obrázek v JPEG, GIF, PNG se musí vždy nejdříve dekomprimovat. Sice na to lze použít GPU (grafický čip), ale výsledek bude nekomprimovaná bitmapa někde v paměti (nejlépe v paměti blízko GPU, tj. v paměti grafické karty, resp. přímo ve framebufferu). Odtud to GPU/RAMDAC čte, když vytváří obraz pro monitor. Framebuffer může být komprimován, ale to je jiný typ komprese a ten mezivýsledek v bitmapě tam stejně někde aspoň chvíli bude. A protože webový prohlížeč (nebo prohlížeč obrázků) do té paměti sahá, musí to být jemu přístupná paměť, a proto bude i vidět v čísle, kterým systém oznamuje paměťovou náročnost programu.[1] Tj. vlastně to až takový problém není, když je prohlížeč nenažranej (spíš je to dobře). Prohlížeč si také musí uchovávat kopie dat i mimo grafickou paměť - např. aby byl rychlý, když zmáčknete tlačítko "zpět" nebo aby měl předem nachystaná data, ještě než kliknete na odkaz (prohlížeče přednačítají stránky, na které byste mohli přejít).[1] ve Windows se běžně používají dost špinavý triky, aby zabraná paměť byla připsána na vrub jinému programu/knihovně (než ve skutečnosti), čímž se jeví například produkty Microsoftu "méně nenažrané", než jsou ve skutečnosti (včetně prohlížečů od MS).
Sice teď budu srovnávat jablka a hrušky, ale vemte si například moderní komprimace u nových video kodeků, obrázků nebo nový způsob aktualizace aplikací od googlu. Uživatelů a obsahu každým dnem přibývá a s tím také celkové požadavky na bandwidth. To že ve výsledku jeden uživatel přenese u zdánlivě stejně kvalitního/velkého média menší množství dat, neznamená, že by jeho v jeho počítači byl méněcenější výsledek. Jednoduše se přesouvají "náročnější výpočty" na stranu klienta - se stoupajícím výkonem a efektivitou většiny koncových zařízení bych řekl, že to ničemu nevadí.(Já například u WebApp, která periodicky aktualizuje stav pomocí json o velikosti cca 400B+http header snížil přenesená data na 150B vč http headeru a to díky zazipování>base64encode [cache, aby server tento úkon nemusel pořád dokola provádět pokud nedošlo ke změně json zdroje] a na klientu potom je, aby přijatá data dekódoval a rozbalil - "výsledek je stejný", množství přenesených dat cca 3x menší)(Ty aktualizace aplikací viz http://www.zive.cz/bleskovky/aktualizace-apl... ...
oprava linku, odkaz zahrnul konec zavorky http://www.zive.cz/bleskovky/aktualizace-apl... ...
PS: Ještě bych mohl zjistit jestli by tento krok nebyl zbytečný na http2/SPDY, nejsem si úplně jistý, jestli tyto protokoly komprimují jenom headery, nebo i data. Potom by asi zipování odpovědi bylo zbytečné.
Zobraz jpeg v irfane a zistíš koľko RAM zaberá (písmenom "i")
A to je právě chyba začátečníků. Jasně, nacpat si na web 4 js frameworky zní cool a začátečník si to ospravedlní tím, že se to stáhne jen jednou.Problém je v tom, že většina komerčních webů má míru okamžitého opuštění dosti vysokou a dost bastlířů používají JS na vše a tak trvá někdy i několik sekund, než se to všechno spojí a zákazník vidí výsledek. A když už jsem za ten proklik zaplatil, tak z toho chci vymačkat maximum a nevidím jediný důvod, proč by měl potencionální zákazník čekat dlouhé vteřiny, když se konkurence načte mrknutím oka.Pravidlo na závěr zní, že když to neumím, použiji javascript.
Kdo není úplný *etard, tak ví, že i dnes záleží na "každém bajtu" speciálně u webů!Velký web = pomalejší načítání = uživatelům se hůře používá + vyhledávací enginy dávají nižší rank a nižší pozice = na stránku chodí méně lidí = MÉNĚ PENĚZ ať už její provozovatel dělá cokoli (pokud to není státní úřad 😀 😀).Navíc zbalastěný web se nejen déle přenáší k uživateli, ale často ho i server déle vypočítává, takže je to pak znát.Jestli má vaše průměrná stránka 2,5 MB a je narvaná scripty, které musí zpracovat server NEBO jestli má jen 250 kB a jedná se o předgenerované HTML za pomoci CMS, které se jen odešle uživateli opravdu SILNĚ poznáte na penězích!!Možná ne, pokud poskytujete něco absolutně unikátního... Ale pokud se jedná o něco, kde je silná konkurence - tak to jste bez šance. Takovou stránkou pak doslova tlačíte lidi ke konkurentovi.
Zni to logicky, ale praxe tomu bohužel typicky neodpovídá.
Otázka je jaká praxe. Rychlost stránek a optimalizace fotek je samozřejmě jen jedna z mnoha věcí, které určují virtuální PageRank u každé stránky nějakého webu. Pak ještě záleží, co tam je, jak je obsah originální a užitečný, kolik a jakých vede odkazů z něj a na něj atd.Protože stejně tak jako jsou bonusy v pageranku, tak jsou taky mínusu a dokonce PENALIZACE.Je to jako v životě - můžete mít šest vysokých škol, skvělou kariéru, vlastní firmu a Nobelovu cenu Míru, ale když pak JEDNOU rozsekáte dětskou školku motorovkou, tak dostanete trest mrti nebo doživotí a jakékoliv Vaše kvality už nikoho nezajímají.Stejné je to i u SEO - můžete si skvěle optimalizovat web po technické stránce, mít tam luxusní obsah a pak si to vezme do rukou nějaké pako, které tam udělá "spam" ve formě "sex, sex, sex..." 3000x ve skrytém textu a Google Vám loupne okamžitě penalizačku +500< pozic až vyřazení z indexu a jste v p*deli! 🙂 😀Navíc zástupci Google se vyjádřili už před dvěma lety, že budou sahat k mnohem větším mínusům, penalizacím a dokonce trvalým vyřazením z indexu... Takže ono stačí, aby takový majitel stránek nebo nějakého eshopu "přestal vyhazovat peníze za drahého konzultanta" a zaplatil si "zaručeně 1. místo ve vyhledávačích" z Bazoše za 2000 Kč jednorázově, překvapivě ho skutečně může na některá keywords získat na nějakou dobu a pak jednou šmitec a může web celý zavřít 😁Nebo k tomu pustí nějakého ťulpase, ten mu tam klidně i chce pomoct, ale udělá tam nějaký nesmysl, třeba různé duplicity atd. a hned ho to hodí třeba +10 pozic.Každopádně ono je to dnes dost propojené, protože jedničky v businessu jsou zároveň i jedničky v SERP vyhledávačů. Jasně, je naivní myslet si, že udělám "nějakou tu optimalizaci" a bude na prvním místě, ale rozhodně se vyplatí na to nekašlat, protože je fajn být třeba alespoň na první stránce než na osmé - tedy úplně mimo organické získávání nových uživatelů/zákazníků.
tak samozřejmě, ale vhodně nakonfigurovaný server komprimuje vše, statický obsah i javascripty přes gzip a ještě lépe s http/2
Netlačí tě, oni to dělají všichni🙂
Kdyby 2,5MB, titulka živě má dokonce 4MB: http://i.imgur.com/yX5P6ZZ.png... a ještě jsou ty skripty rozeseté mezi víc jak dvacet domén reklamních serverů, google, adobe a nevím co ještě.
Palec hore Kubovi. Za odmenu som poklikal pár reklám. :)
jojo, bejvaly to zlatý doby úspornejch webů, když se na net lezlo vytáčením na modemu a rychlost byla reálně od 20 do 40 kbpstehdy byla stránka s článkem na zive.cz načtená mnohem rychlejc než dneska na lajně0 200 Mbps, tehdy ani nebyly potřeba blokovače reklam, který dneska jsou nutností...a úplně nepochopitelný je pro mě i to, že taková balastu zbavená stránka si stáhne nějaký 3-4 MB dat, ale zobrazení tý stránky v panelu ukousne 150-200 MB raměti...
Už na dialupu jsem používal webwasher který pouze blokoval obrázky o velikosti reklamy. Tehdy ještě na Netscapu :) a to byl rok 97-98
Autor chtěl asi ukázat bitové operace, tak tu teplotu skládá, ale je dobré si uvědomit, že těch 8 bitů tam v tom floatu už je. Stejnou práci by zde udělalo vynásobení té teploty 4x a zaokrouhlení na int, nebo lze z toho floatu vytáhnout exponent přímo a prostě to celé jen posunout doprava, tam se bitové operace využijí taky.Co se týče těch webů, kde jsou pod sebou 4 obrázky na celou stránku a na každym 1 věta textu a do stránky přibaleno 10 js frameworků aby se to hýbalo, to už asi nikdy nepochopím.
Protože je na ní milion reklam.
Na někdejších sálových počítačích bylo opravdu málo paměti, třeba EC1021 měla jen 64kb na feritových jádrech, takže to zabíralo 2 skříně. A tak se takové postupy pro šetření paměti opravdu využívaly. Z tohoto pohledu je vlastně každá dnešní průměrná webová stránka v podstatě také doom? 😉
Potvrďte prosím přezdívku, kterou jsme náhodně vygenerovali, nebo si zvolte jinou. Zajistí, že váš profil bude unikátní.
Tato přezdívka je už obsazená, zvolte prosím jinou.