Senki nem beszelt egy nagysagrendi kulonbsegrol, ezt te huztad elo a hajanal fogva. Az XML-ben valo utaztatasrol van szo, annak pedig nincs egy nagysagrendi overheadje akkora adatfolyamnal, amirol szo van. Ketszeres? Lehet. De az meg mindig kevesnek szamit. A fenti peldanal durvan husszoros meretrol volt szo, de 23 kilobajt feldolgozasa azert meg mindig kevesnek szamit. Ha 1 es 10 giga kozotti ertekrol lenne szo, igazad lenne, igy nincs. A halozatos peldadra is ugyanez a valasz: az 1 es 2 csomag feldolgozasa kozott _nincs_ ertekelheto idobeli kulonbseg.
Egyebkentm egg a CPU meg a memoria veges eroforras, ebben igazad van, de akkor szuntessuk meg a nyiltszoveges protokollokat, es menjen minden binaris adatfolyamban, stopbit, startbit, 4 byte mezomeret, adat, stopbit, startbit, s.i.t. Baromi jo, csak valoszinuleg nem veletlenul lettek az XML-szeru szabvanyok kitalalva. Mert nem minden a CPU es a memoria.
Egyebkent pedig ez foleg eszkozfuggo is. Nekem is volt kozom manualisan irt XML parzeres szornyedvenyhez, lassab kodot talan sose lattam, ki lett cserelve standard parzerre es lecsokkent a teljesitmenyigenye ket nagysagrendet. Ha valaki szarul valasztja meg az eszozeit, az ne csodalkozzon a szar teljesitmenyen. Ez igaz a find-es peldadra is.
Probald meg mar kontextusaban ertekelni, amit irok. Megfigyeltem, hogy abbol, amit mondok, mindig valami altalanos ervenyu kinyilatkoztatast akarsz faragni, es ez altalaban messze nem igy van. En mindig arra reagalok, amit mondanak, nem pedig masra. Nem baj, csak magadnak csinalsz teljesen feleslegesen problemat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.