Ma a számítógépem tápegységét szerelgettem (ventilátor csere), és nem kapcsolt be. Jó nagy … kulimászban vagyok, ötlött fel bennem. De mi is az a kulimász?

kulimász

főnév,

1. ragadós massza, kenőcs. Eredetei jelentése kocsikenőcs, a szekér tengelyének kenésére szolgáló zsír.
2. átvitt értelemben baj, kellemetlen helyzet. Például: Benne van a kulimászban

Szláv eredetű szó. Szerb-Horvát nyelvekben kolomaz, oroszul коломазь (kolomazʼ). Kocsizsírt jelent. A protoszláv kolo (“kerék”) + mâzь (“kenőcs”) tövekből származik.

A tápegység javítása amúgy sikeres volt, mindössze elfeledkeztem egy kábelkorbács alaplapra bekötéséről👏. Régen nem csináltam már ilyet. 😒

Kedvenc hobbi projektemen, a világ legjobb Praegustator-ján dolgozva eljutottam a pontra, hogy van némi kód, ami működés szerű jeleket produkál, úgyhogy a verziókövetés után ideje CI-t is csinálni neki.

GitLab CI

Mivel a projektet jelenleg a GitLab szolgáltatásában tárolom, gondoltam ideje kipróbálni a CI szolgáltatásuk is. Elégedett vagyok a szolgáltatásukkal, egész jól dokumentált, intuitív. Nekem elég az ingyenes csomagjuk is, mivel néhány havonta pár nap pár commitot foglalkozok csak a projekttel, de amúgy sem túl drága a szolgáltatásuk. Amúgy a TravisCI által meghonosított a git repository gyökérkönyvtárában levő, a kóddal együtt verziózott CI recept alapú megközelítést alkalmazzák, ami jelenleg a legjobb módszer szerintem a CI-ra. A vetélytársaikkal ellentétben azonban a privát repositorykra is elérhetőek a CI buildek, bőséges ingyenes beetetős build kapacitással. Ezen kívül build artifacteket is kezel a rendszer.

Összességében a GitLab CI-t egy kellemesen használható eszköznek találtam, bár voltak döccenők a build file tesztelése során, de ezzel együtt is ajánlott eszköz.

Mostanra mondjuk a Microsoft Azure DevOps Pipelines is kezd felzárkózni, már az is tudja a kód mellett verziózott build recepteket, konténer alapú build környezeteket, és szintén tekintélyes mennyiségű ingyenes privát buildidős kapudrog jár a szolgáltatásaikhoz, ráadásul Windows alapú build környezetek is elérhetőek elvileg. (Ezt még nem próbáltam, de kilátásban van, hogy szükségem lesz rá. Majd beszámolok a tapasztalatokról, ha lesznek.)

A CI receptet tehát gyorsan felélesztettem, és gondoltam jó lenne egy kis code coverage a tesztekhez. Nosza, nézzük meg, mik a lehetőségek a .Net Core világában!

Teszt fedettség mérés, ahogy azt a Microsoft elképzeli

A Microsoft állítólagos legendás megújulása még gyerekcipőben jár. Még mindig a GUI nyomkodós, scriptelést VBA Excel makróban elképzelő szemlélet uralkodik sajnos például a tesztek fedettségének a mérése területén.

Megnéztem, mik a lehetőségek megmérni a kódom tesztfedését, és megdöbbenve láttam, hogy csak a Visual Studio Enterprise csomagban található a szükséges eszköz. Standalone nem érhető el, se ingyen, se pénzért. Meg kell venni a fejlesztőkörnyezetet, ami első évben 6000$, majd 2570$ évente! Nem fogom az EULA-t elolvasni, de a build gépre tuti kellene még egy licenc, ahogy ismerem őket. Nem igazán érzik, hogy mi a minimum amit manapság ingyen kell adni, ha a platformodra akarod a fejlesztőket csábítani. Viszont már lehet cli-ből használni. Miután a 20 Gigabyteos devenvet feltetted. 😩

Szerencsére a GitHub hibajegy vége felé saját ingyenes, nyílt forráskódú termékét hirdeti alternatívaként egy hozzászóló, a kiváló Coverlet-et.

Coverlet

A Coverlet ingyenes, nyílt forráskódú, és nekem épp eleget tud. Ráadásul könnyű használni, és egyből működik, minden komplikáció nélkül!

A GitHubon itt, NuGeten pedig itt lehet elérni.

Lehet parancssorból vagy msbuildből használni. Én egy pár soros kimenet feldolgozó scripttel integráltam a GitLabos buildemhez az msbuild változatot.

Többféle elterjedt kimeneti formátumot támogat a saját json alapú kimenetén felül, hogy könnyebb legyen integrálni meglevő rendszerekkel. Én a cobertura formátumot használtam fel.

Osztály fedést, metódus fedést, sor fedést (statement coverage) és elágazás fedést (branch coverage) mér, a komplexebb MCDC fedést nem méri, viszont nyílt projekt, akinek erre van igénye, szerintem bátran felajánlhatja a közösségnek a fejlesztését 🙂.

Amennyiben a kód fedettsége egy kritikus szint alá esik, el tudja buktatni a buildet igény szerint.

Különböző kódok kizárhatóak a mérésből (pl. WCF generált kód esetén lehet értelme). Ezt lehet a parancssorból, vagy attribútumokkal annotálás segítségével is elérni.

Összességében nagyon jól használható eszköz. Eddigi Microsoft utilitykkel kapcsolatos élményeim alapján az a gyanúm, hogy már most jobb mint a Microsoft aranyárban mért terméke, ráadásul nuggettel telepíthető a projektbe, nem kell egy teljes fejleszői környezetet feltenni hozzá a build gépre.

Nekem nagyon tetszett, azon ritka szoftverek egyike, amit azonnal megszerettem, és a használata során sem utáltam meg, egy kicsit sem! Pont azt tudja amit akarok, és könnyen lehet használni. Ajánlom mindenkinek! 💯👌

A minap hallottam, hogy valaki azt mondta: Még be kell menjek a RÖLTEXbe. Persze tudom, hogy a RÖLTEX az varráshoz szükséges segédanyagokat árul, de honnan is jött a cég neve?

Röltex

főnév,

1. Betűszó, a szocializmus alatt, 1950-ben alapított a RÖvidáru-LakásTEXtil Vállalat egy kiskereskedelmi lánc, és a nevében foglalt árucikkek kereskedelmével foglalkozik.

Jobban belegondolva nekem is be kellene mennem a röltexbe, elromlott a cipzár a kedvenc kabátomon.

Az idén eddig már kétszer sikerült túrázni eljutnom, ami még mindig fájóan kevés, de legalább több mint tavaly. Júliusban sikerült megismernem a festői szépségű Spartacus-ösvényt, aminek bejárását mindenkinek javaslom.

Könnyű túrát terveztünk, úgyhogy gépesítve terveztünk helyzeti energiát szerezni, melyet ereszkedéssel kinetikus energiává alakítva kevés fáradtsággal tudunk élményekre szert tenni. A szervezés olyan körülményesre sikeredett, hogy az eredeti bivakolás később kempingezéssé szelídült, majd miután az időjárás-jelentés okozta vaklárma okán pár héttel korábban lefújtunk egy alkalmat ekkor már a szemerkélő eső ellenére is elindultunk, igaz csak egy egynapos kiruccanásra.

Az eredeti útvonal helyett az utolsó pillanatban döntöttünk úgy, hogy a Dobogókő - Pilisszentlászló - Visegrád utat tesszük meg. A terv szerint az útvonal Dobogókőtől a piros háromszög, majd piros kereszt úton át megy Pilisszentlászlóra, ahonnan a zöld úton át Visegrádon ér véget.

Dobogókő

A busz lassan vonszolta magát, és bár a mellettünk folyamatosan szellentő kutya a busznak nem segített, de ez az élmény eléggé belém égett, hogy egy időre ne akarjak sárga buszra szállni. A gazdáját kiválóan szórakoztatta a szituáció. Valahogy én is kibírtam a szagokat.

Dobogókőn a szívcsakra helyett egy számomra nyomasztóan kiépített hely fogadott. Ha már így alakult, akkor egy finom kávét vettünk indítónak egy szimpatikus büfénél. Egy étteremnél az udvaron vaddisznó-pörkölt készült bográcsban a hívogató tábla tanúsága szerint. Ezek az illatok végre kellemesek, hívogatóak voltak.

A Dunakanyar felé néző kilátót hamar megtaláltuk. A kilátás szép volt, de a borús idő miatt itt nem láttuk még a Dunakanyart teljes pompájában. Hallhattunk azonban részleteket a transzneműek szerepéről a StarTrek világában más túrázóktól. Úgy ítéltük meg, hogy túl sok itt a városi. Inkább utunkra indultunk valami kiégett, omlásveszélyes épület mellett a piros úton.

Irány Pilisszentlászló

Az út első fél órája eseménytelen volt, miután letiltottuk a különféle szoftveres segítségek idegesítő kuruttyolásait. A kellemes csendben miután először találkoztunk más túrázókkal sikeresen eltévesztettünk egy kanyart, és letértünk az útról. Erről persze csak később értesültünk, hála a letiltott figyelmeztetéseknek, amelyek akkor is erre figyelmeztettek, amikor még a tervezett úton haladtunk 😒.

Ha már így jártunk, akkor vissza ugyan nem fordulunk! Erdészeti ösvényeken, csapásokon át tértünk vissza az útra. Ennek a szakasznak a felénél lehetett, amikor a derékig érő fűben gázolva a tüskés bokrokat félrehajtogatva mentünk egy egykor terepjáró autóknak is járható úton, és jobb felől a bozótoson túlról az erdőből meghallottunk valamit. Valami nagyot. Nagyon nagyot. Az a mondás az itthoni vadakkal kapcsolatosan, hogy nem kell tőlük nagyon félni, mert jobban félnek tőlünk. Egy pillanatig szerintem nem állt ez az egyenlőtlenség.

A piros útra visszaérve időszerű lett az energiabevitel, úgyhogy kerestünk egy nyugodt helyet, ahol teát főzhettünk, és megebédelhettünk. Tovább indulva kipróbáltam új, olcsó ivózsákomat (Auchan sajátmárkás). A víz ihatatlan műanyag-ízű volt, a szaga is kellemetlen műanyag-szagú volt. Azóta próbáltam mindenféle javasolt praktikákat , de továbbra is olyan maradt, ahogy következő túrámon tapasztaltam. Vettem inkább egy Decathlon sajátmárkásat. Ez nem büdös, de még nem volt alkalmam kipróbálni.

Innen hamarosan elértük Pilisszentlászlót, ahol megtaláltuk a Kéktúra két pecsétjét is, valamint egy öreg Praha gyártmányú teherautót. Egy kocsma/kisbolt hibrid még szombat délután is nyitva volt, így feltöltöttük folyadék tartalékainkat, és kidobtuk az ebéd óta hurcolt szemetünket.

Mivel a késett indulás és eltéveszett út miatt itt már jelentős késében voltunk az eredeti tervekhez képest, ezért erősen bele kellett húzni. Ezen a szakaszon azonban olyan látványos útban volt részünk, ami ritka az itthoni túraútvonalak közt.

Körülbelül negyed órája hagyhattuk el Szentlászlót, amikor egy táblára lettünk figyelmesek, mely látszólag a lovas útvonalon volt. Ez a Spartacus-út fokozott nehézségére hívta fel a figyelmet. Később azonban gyanús lett, hogy mi magunk is ezen az úton járunk, és a felhívás nem a lovasoknak szólt.

Spartacus ösvény

A Spartacus-ösvény egy egykoron vadászok által használt útvonal, melyen anno Horthy-Miklós is vadászott. Az 1930-as évek környékén alakította ki a pilisi vadásztársaság. Ahogy a Spartacus névből is sejthető a kommunista diktatúra idején kapta a nevét. Az “ókor szocialista hőséről” elnevezett sportklub neve ragadt végül az úton valahogy. A természetjárók sok éven át aktívan lobbiztak a vadásztársaságnál az út turisták előtt megnyitásáért, ám erre egészen 2015-ig várni kellett.

Nem véletlen vannak kint a figyelmeztető táblák (a fotó az ösvény visegrádi végén készült), és nem véletlen nem lelkesedett a vadásztársaság a széles közönség előtti megnyitásért. Az út bár – átlagos erőnléttel könnyen letudható – néhol elég keskeny, van ahol csak egy cipőnyom széles, és oldalt kiadós esés majd gurulás vár az óvatlan túrázókra. A készített képeim ezt sajnos nem adják jól vissza, de azért néhányat megosztok.

Szarvas-bérc

Bár már siettünk, de mind az út egy-egy nehezebb része, mind a kilátás meg-megállásra csábított. Mészkő oszlopok, melyek akár még a római-kori erőd maradványai is lehettek, érdekes sziklák, kidőlt vagy épp lenyűgöző helyeken növekvő fák szegélyezték utunk, amikor egy hegytetőre vezető ösvényt találtunk. Mivel ezen a szakaszon a becsültnél jobban haladtunk, ezért rátértünk az ösvényre. A meredek, és a morzsalékosság miatt néhol meg-megcsúszó ösvény kicsit elbizonytalanított. A Szarvas-bérchez vezetett ez az út, ahol fenséges kilátás tárult elénk, feledtetve a sietséget, a gördülő köveket.

Tovább a Spartacus-ösvényen

Miután kigyönyörködtük magunk folytattuk az utat, abban a reményben, hogy elérjük az utolsó kompot, vagy a 8 órai buszt. Szép volt az út, de a legszebb része csak ekkor jött. Itt voltak a legmeredekebb hegyoldalak a legkeskenyebb ösvényekkel is. A képeken útitársam – egyben lábdublőröm – szemlélteti ezt.

A szép kilátású meredélyes szakasz után erdő következett, ahol a Jenő-kunyhó nevű épületre bukkantunk. Az épület egykori vadászház, de nyitva áll az ajtó és be van rendezve. A berendezés része egy fűrész és fejsze, ami a kunyhó melletti tűzrakóhely felélesztéséhez hasznos, de egy poloskás penészes szivacsú ágy is, amit nem értek miért hagytak ott. Összességében nyomasztó a ház belseje. Túl sok a kacat, ami miatt a kosz is. Az épületet egyébként Horthy Miklós építtette, Jenő nevű testvérének emlékét őrzi neve.

Visegrád

Egy gyors uzsonna után rohamtempóban haladtunk Visegrád felé, kis fahidakon és szép ösvényeken át. Az utolsó szakaszt már aszfalton és erőltetett menetben tettük meg. A busz azonban a menetrend előtt pár perccel érkezhetett, mivel odamenet az utolsó néhány perces egyenes úton sem láttuk elmenni, majd hiába vártunk rá percekig. Az ekkor befutó komp személyzetétől megtudtuk, hogy több komp már nem indul aznap Nagymarosra, így nem tudunk vonattal hazamenni.

Más lehetőség híján egy vendéglő udvarán egy-egy pohár bor mellett vártuk be az utolsó buszt Szentendre felé, majd a HÉV-vel visszatértünk a nátriumlámpák borostyán derengésébe.

Praegustator

Egy ideje elkezdtem egy régóta halogatott projektemen dolgozni. Ez egy olyan program lesz, ami gépi tanulás (jobban hangzik mint a statisztika 😉) segítségével fogja a híreket kategorizálni, előszűrni számomra. Legalábbis egyelőre ez a célom. Ezért lett a neve Praegustator.

Mivel még erősen fejlesztés alatt áll a program, és a feldolgozó csővezeték még sokat változhat, ezért a letöltött cikkeket mentem, hogy amennyiben módosítom a feldolgozó futószalagot, akkor meg tudjam ismételni a feldolgozást, és a modellt az új kimenet alapján újra tudjam tanítani.

Közel egy hónapja fut már egy verzió tesztüzemben, és több mint 1GB már az adatbázis mérete. Megvizsgálva az adatbázist több tanulságot levontam. Egyfelől az adat felét a mentett cikkek törzsei teszik ki, másfelől a kinyert szöveg-jellemzők tárolási formátuma is erősen pazarló.

Mivel a szöveg-jellemzők valószínűleg SQL lekérdezésekkel (is) feldolgozva lesznek, ezért ott egy tömörített bináris blobban tárolás nem megoldás a helytakarékosságra, ezért ott inkább a reprezentáció finomhangolásával nyertem némi helyet.

A cikkek szövegtörzsét azonban csupán mentéskor egyszer írom, és csak akkor olvasom, amikor egy módosítás után a szöveg-elemző futószalagban az elemzés kimenetelét újra kell generálni. A feldolgozás nem SQL-ben, hanem a C# alkalmazásban történik.

Ezen szempontok figyelembevételével úgy döntöttem, hogy az eddig szövegként tárolt HTML szövegtörzs helyett azt tömörítve fogom tárolni. Már csak a tömörítési eljárást kellett kiválasztani.

A Weissmann-átlag

A Silicon-Valley című méltán sikeres amerikai vígjáték sorozat első évadjában lehetett a veszteségmentes tömörítések jellemzésére használt – a sorozat kedvéért megalkotott – Weissmann-átlaggal (angolul Weissman-score) találkozni.

Mivel nagyon professzionális vagyok, ezért úgy döntöttem, hogy a tömörítési eljárás kiválasztását illendő lenne empirikus úton, mérésekre alapozva végezni, de jó móka lenne ezt a Weissmann-átlagot is kiszámolni.

A Weissmann-átlag, amint már írtam, egy film kedvéért kitalált áltudományos mérőszám, veszteségmentes tömörítő algoritmusok összehasonlítására.

A képletből látható, hogy ez abszolút összehasonlításra sajnos nem igazán alkalmas, legalábbis a referencia értékek (skálafaktor, tömörített adatok, referencia algoritmus tömörítési aránya és futásideje) megadása nélkül.

A mérés

Mivel az alkalmazásom .Net Core 2.0 alapon fut, így eredetileg ott mértem meg az elérhető algoritmusok teljesítményét.

A következő algoritmusokat vetettem össze:

1. Gzip – a .Net keretrendszer részeként elérhető
2. Deflate – szintén elérhető a keretrendszer részeként, a Gzip algoritmus ezen alapul
3. Bzip2 – Linux alatt népszerű, a gzipnél tömörebb, de lassabb algoritmus. Mivel a keretrendszer nem szállítja, ezért egy külső managelt könyvtárral próbáltam ki: [SharpZipLib 1.0.0-alpha2(https://www.nuget.org/packages/SharpZipLib/1.0.0-alpha2). Natív kóddal feltehetően gyorsabb lenne.
4. Brotli – A Google új üdvöskéje. Natív .Net Core megvalósítás: BrotliSharpLib 0.2.1

A keretrendszer következő, 2.1-es verziója azonban natív Brotli támogatást fog hozni, így átálltam egy előnézeti verzióra, hogy annak a teljesítményét is össze tudjam vetni a többi versenyzőével. Így a Brotli kétszer is szerepel a mérésekben.

Minden algoritmusnak vannak különféle beállításai. Én mindegyiknél a leggyorsabb és legtömörebb módokat próbáltam ki, nem finomhangoltam egyiket sem.

A méréseket egy ~80 MB méretű adatbázis mentésből kinyert korpuszon végeztem. Az adatok mentett HTML dokumentumok, magyar és angol nyelveken vegyesen.

A mérést nem mikrobenchmarkként végeztem, nem ismételtem meg többször, nem számoltam szórásokat. Nekem most elég jó volt egy egyszerűbb mérés is.

Eredmények

Az eredményeket a mérőprogram csv formátumban elmentette.

Adat elemzés, egy csipetnyi Excel gyűlölettel

Az adatok feldolgozásához úgy döntöttem, hogy kipróbálom az Excelt. Elég kevéssé ismerem, és vannak, akik erre esküsznek. Nekem eddig csak csalódásokat okozott, mindig jobban működött egy Python scriptet összedobni, mint a táblázatkezelővel szenvedni, de még programozó kollégák is azt állítják, hogy van, hogy az Excel legjobb választás adat turkálásra. Gondoltam adjunk még egy esélyt neki!

Kipróbáltam.

Tévednek.

Amennyit küzdöttem vele, az alatt Python segítségével többször is elvégeztem volna amit akartam, és így sem vagyok teljesen elégedett a kapott grafikonokkal. Az adatból másfajta adatok kinyerésével nem is próbálkozom már, annyira körülményes, elmásznak az oszlopnevek, meghülyülnek a képletek.

A transzponálással külön meg kellett küzdenem. Szánalom.

1. Jelölj ki egy pont akkora területet mint a transzponálandó transzponáltja!
2. Ne nyomj entert,
3. hanem nyomj Ctrl+Shift+Entert!

A CSV import elég awkward, és frissíteni sem lehet lehet könnyen, de azért adatkapcsolatként szerepel, amit törölni kell és újra betölteni a filet egy újabb mérés után. Egy Python script esetében ez felnyíl-enter lenne. Ehelyett 20 kattintás, ha más a sorok száma, akkor képletek frissítgetése…

Most képzeljük el, hogy szórásokat is számoltam volna, több adatsort kellett volna korreláltatni hozzá azonos elem különböző méréseiből. Erre teljesen alkalmatlan eszköz az Excel.

Egy olyan scatterplot, amiben van értelmes jelmagyarázat is, és címkéi is vannak az adatpontoknak… Feladtam ott, hogy legalább a pontokra sikerült felrakni a címkéket.

További számításokat nem végeztem inkább, másfajta plotokat sem készítettem. Egyszerűen alkalmatlan komolyabb adatfeldolgozásra. Varázsbillentyűk. Képlet frissítés után gondosan copy-pastelni végig a sorban/oszlopban. Nem értem milyen elme tud így gondolkozni. Nincs absztraháló ereje, teljesen ad-hoc, átláthatatlan. Vagy valaki olyan, akit beleszoktattak ad-hoc hülye eszközök használatába, és ettől torzult az elképzelése egyes munka/kognitív folyamatokról. Talán egy könyvelő? Az adószabályok, a főkönyv számozott-elnevezett kategóriái, és az ÁNYK hasonló pokolbéli kínzóeszközök… Azok után az Excel akár tűnhet is megfelelő eszköznek.

A Weissmann paraméterek

Ahogy a táblázatból is látható, a gzip algoritmus Optimal (linux világban gzip -9) változatát tekintettem referencia algoritmusnak. A skálafaktor értéke α = 1 volt.

Lássuk már az eredményeket

Algoritmus	Idő [sec]	Tömörítés	Sebesség [Mbyte/sec]	Weissmann átlag α = 1
gzip	0,562755	4,241916	138,625	1,0000
gzipfast	0,221613	3,761087	352,020	0,7391
deflate	0,457420	4,243974	170,548	0,9579
deflatefast	0,214454	3,762704	363,771	0,7351
bzip	9,942345	4,549692	7,846	2,7860
bzipfast	9,717193	4,519541	8,028	2,7327
brotli	88,602744	5,325078	0,880	-15,0365
brotlifast	0,926333	1,953454	84,216	0,5155
brotlicore	44,596294	5,324878	1,749	19,7554
brotlicorefast	0,209611	3,835408	372,175	0,7463

Ugyanez képen

Végkövetkeztetés

Mivel a Brotli tömörebb, bár nagyságrendileg lassabb, arra esett a választásom. A Gzip általában jó választás, fast módban is egész jól tömörít, nagyon gyorsan, de arra jutottam, hogy mivel elég sok cikket kell majd tárolnom, de nem nagyon nagy tempóban érkeznek, ezért jobban megéri alaposabban tömöríteni. Egy dokumentum tömörítése még így átlagosan is 10ms alatti (A BrotliSharpLib legtömörebb módjával), és jelenleg 15 percenként néhány tucat dokumentum érkezeik csupán. A Brotli kitömörítési sebessége a gzipével összemérhető elvileg, de azt nem mértem meg.

A Brotlit amúgy kifejezetten webes tartalom tömörítésére találták ki, a leggyakoribb angol szavak és HTML tagek is szerepelnek az előre generált szótárában, aminek köszönhetően ilyen tartalmat még hatékonyabban tud tömöríteni. Ezért is gondoltam, hogy most jó választás lehet számomra.

Jelenleg a managelt BrotliSharpLib megoldását használom, majd a framework 2.1-es verziójának kiadása után frissítésekor átállok a Microsoft megoldására, mivel az közel kétszer gyorsabb. A biztonság kedvéért kipróbáltam, és a két megoldás kimenete szinte azonos, méretben is csak néha akad néhány byte eltérés. Egymás kimenetét sikeresen ki tudják bontani. Résen kell lenni, az ördög nem alszik!

PiedPiper

Bár az általam számolt Weissmann átlagokkal a SiliconValley sorozatból ismert értékkel nem lehet közvetlenül összevetni a PiedPiper Weissman számát, én megteszem!

A filmben az érték az elképesztő 5,2-re adódott, amitől mindeki el volt alélva! Ezt azzal érték el, hogy egy 132 GB méretű filet 24,35 GB-ra tömörítettek 12 másodperc alatt.

Nekem a .Net Core 2.1-es Brotli 80MB-ot 15MB-ra tömörített 44 másodparc alatt, és ez 19 pontot ért az én összehasonlításomban

A győztes tehát egyértelműen a… na jó, ennek tényleg semmi értelme :)