( bucko | 2018. 12. 08., szo – 00:32 )

Ahol is a idézet arrol szól, hogy: a nembloat word-doc bináris elkészitése mégis 10x annyi ideig tartott, és kétszer annyit foglalt, mint a bloat(tm) nemdoc.
No, én meg pontosan azt írtam, hogy mindkettő nevetségesen lassú. Ha úgy tetszik, akkor a bloatabbnál bloatabb dolgokkal versenyeztek. Ugyanúgy, mint a browserek: Az egyik 5-20-stb. százalékkal gyorsabb a másiknál. Na és? Mindkettő rohadt lassú.

Az, hogy 10 évvel sem tarthatott _volna_ az nem érv. Vagy mutass hasonló volumenű feladat/megoldást, ami 10 éve annyi idő alatt teljesült, ahogy elvártad, ilyen adatnál.
Közben megtudtuk, hogy kb. 3,000 szerződésről van szó. Sajnos ez nem fog menni, mert ilyen kevés adattal nem szoktam dolgozni. ;) Gondolom, kb. név, cím, telefonszám, határidő, összeg - ilyen adatokat kellett az egyes szerződésekhez adatbázisból kiolvasni és a szerződésben helyettesíteni.

Amire a becslésemet alapoztam:
1) Dolgoztam 7/14M adattal. (A 7M a "kemény adat", a másik 7M nem túl lényeges adattartalmú rekord.) A formátum több forrásból tömörítve érkezett (tömörítetlenül kb. 1GB), és "kiterítve" 3,6GB végeredménye lett. A feldolgozás közben az egyes rekordokat
- Mezőkre kellett bontani. (50 mező)
- Adatbázis alapján kiegészíteni.
- Néhány mező alapján néhány indexhez való adatot kigyűjteni, javítani vagy helyettesíteni.
- Vertikális hierarchiát követni és az index mezők tartalmát ennek alapján igazítani.
- Kiírni egy másik (bináris, de ez lényegtelen) formátumba.
- Részfeladatként a 7M adatból kiválasztani 0,5M adatot, és ezt a 0,5M adat + adatbázis alapján módosítani.
Természetesen nem írtam le az egész feladatot, de úgy érzem, egy "picikét" túlmutat a 3000 dokumentumot minimális módosításán és kiírásán.

No, a fenti feladat futásideje - az egyéb terheléstől függően - 65-85s között volt 10 éve.
Az eredményt kissebbíti, hogy ez egy kicsi szerveren futott, de azért a 10 év és a doc formátumoknál feldolgozott jóval kevesebb adat alapján nyugodtan lehet <<1perc becslést tenni.

2) A második szempont - mint írtam a szűk keresztmetszet - a diszk sebessége, mert az eredményt ki is kell írni. Így aztán az első esetben (dupla adatmennyiséggel számolval) 0,164MB/s, a másodikban (a tömörítés miatt még háromszoros adatmennyiséggel számolva) 0,6MB/s a feldolgozás sebessége. Tehát nem a diszk a szűk keresztmetszet. Ezt vesd össze a 10 évvel ezelőtti >50MB/s feldolgozási sebességgel!

Akkor meg vajon mi fut ilyen lassan az i5-ös procin? Tényleg ennyire gagyi lenne?

A szavaidon lovaglás egyszerű. Mindig mondom az anti-sebességmániás fiataloknak, mint a Terminátorban: Ha egy mikromásodperccel lekésed a diszk fordulatot, akkor rögtön 10000x lassabb lehet a program. Ebben az esettben nem ilyen rossz a helyzet, csak a feladathoz mért sebesség kb. 50x kisebb az elvárhatónál. És ez így jó, mondá az Úr, hiszen eddig csak bloatot látott!