Adatok olvasása memóriából és háttértárolóról
2010-11-06T16:01:51+01:00
2010-11-08T20:53:49+01:00
2022-06-30T13:12:12+02:00
  • érdeklődés ill próbálom kímélni a rsz-t és hardware-t a fölösleges hibajavítástól
    Mutasd a teljes hozzászólást!
  • Van valami konkrét feladatod, vagy csak úgy érdeklődsz?

    Mert egy 100 megás fájlt tök felesleges 4 kb-onként olvasgatni, egy 3 terrásat meg nem.
    Amúgy is, mint ahogy mondták az oprendszer cachelni fogja az egészet.
    Mutasd a teljes hozzászólást!
  • ill. mia helyzet olyan esetekben amikor ezzel nem osztható a fájl méret inkább egybebeolvasni hamég nem érte el egy opt max határt
    vagy több darabban (máramennyiben tényleg beakarjuk olvasni a maradékot)
    Mutasd a teljes hozzászólást!

  • köszönöm
    akartam is kérdezni
    és mennyire tennétek ezt az értéket?
    min-max
    ill. mikor javasolt a nagyobb?
    Mutasd a teljes hozzászólást!
  • Nyilván minél többször (=kisebb egységekben) olvasol, annél lassabb. Manapság a legkisebb praktikus egység a 4KB.
    Mutasd a teljes hozzászólást!
  • teszemföl nem ússzuk meg hogy winyóról kell olvasni és feltételezzük hogy memóriába olvashatunk, épp van elég szabad:
    hogyan oldja meg ezt az op rsz (melyik kíméli jobban az olvasófejet?)


    A vinyó szempontjából nem lesz különbség, mivel az oprendszer úgy is teljes blokkokat olvas a lemezről, és belső pufferben tárolja azt a részt, amit még nem olvastál ki. (Ezt a pufferelést le lehet tiltani, de akkor meg az oprendszer csak egész blokkokat hagy olvasni, egy bájtos olvasásra pedig hibát ad.)

    Amiért mégsem érdemes egyesével olvasni a bájtokat, az a CPU-használat. Minden bájthoz kell egy új Read függvényhívás, és ha a Delphi nem tart fenn saját puffert(*), akkor még kernel módba is be kell váltani az olvasást végző rendszerhíváshoz.

    Ezek a hatások az olvasás méretének növekedésével csökkennek, pár kilobájtos puffer esetén általában már elhanyagolhatóak.

    (*) Ha jól tévedek, a Delphi tart fenn saját puffert minden nyitott fájljához, de erre most nem vennék mérget.
    Mutasd a teljes hozzászólást!
  • a 2. paraméter lehet változó ahova beolvassa
    de nem pontosan írtam
    Mutasd a teljes hozzászólást!
  • A 'Read'-nek (ha jól csalódom) szokott lenni egy 'hová' paramétere is.
    Mutasd a teljes hozzászólást!
  • PHP szerver oldali nyelv esetén


    itt csupán csak arra gondolok szoktak-e programozási nyelvekben/ op. rendszerekben elérően kezelni egy adatolvasás háttértárolóról/ memóriáról kérdést

    köv kérdés:
    teszemföl nem ússzuk meg hogy winyóról kell olvasni és feltételezzük hogy memóriába olvashatunk, épp van elég szabad:
    hogyan oldja meg ezt az op rsz (melyik kíméli jobban az olvasófejet?)

    Delphi-s pl ban:
    // max: mennyi adatot olvassunk ki
    AssignFile(f, fn); Reset(f); for i:= 1 to max do Read(f,1);


    AssignFile(f, fn); Reset(f); x:= Read(f,max);
    Mutasd a teljes hozzászólást!
  • pl ez az objectumorientált programozás dolog vagy annak a címén úgy látom kicsit túlzottan elment abban az irányban pl egy komponens mindent tud (kivéve főzni és vasalni)


    OOP inkabb azt hirdeti, hogy a "komponenseidnek" egy dologra kell szakosodniuk, az altalad latott memoriapazarlasnak semmi koze a hasznalt paradigmahoz.

    szóval még várom az 5leteket, ill. ki hogyan látja miaza határ aminél azt gondolja ő x% ezt használja y% ezt


    Ha vegiggondolod, ez a kerdes ennyi informacio mellett butasag. Ketten irtak nagyon helyesen, hogy talan tudni kene, hogy a programod hogyan hasznalja a merevlemezen levo adatokat. A RAMbol mindig gyorsabb olvasni, mint a merevlemezrol, viszont kevesebb van belole. Ha egy beolvasott reszre kesobb tobbszor is szukseged lesz, lehet, hogy megeri ramban tartani. Ha nem, akkor meg... talald ki!

    Lehet, hogy erdemes letrehoznod a fajlrol valamifele indexet, amit a memoriaban tarthatsz, igy legalabb a kereses gyorsan megy.

    Nem a kézenfekvő megolvás hanem a leginkább erőforrás és memóriahasználat-kímélő megoldás érdekel.


    Tehat nem baj, ha a szamitas 4 orat tart, a fo, hogy minimalis ramot es procit hasznaljon..?

    És ez hogyan függ egy gép konfigjától?
    Kihegyezve érdekel PII->PIII gépre ajánlott arányok
    64->500M memórával


    Minel kevesebb a ram a gepben, nyilvan annal dragabb. Minel tobb alkalmazas fut a gepen a tied mellett, annal kevesebb jut a tiednek, meg gyakrabban kenyszerul az OS swappolasra, ezzel csokkentve a teljesitmenyt.

    PHP szerver oldali nyelv esetén


    Ez hogy jon ide..?
    Mutasd a teljes hozzászólást!
  • Nem árultad el, hogy mit akarsz csinálni a fájllal. Ha csak egyszer símán végigolvasni, akkor az open/read/close műveleteket érdemes használni.
    Mutasd a teljes hozzászólást!
  • Azt hiszem, hogy a kulcs a kérdésedre abban van elrejtve, hogy te Delphi programozásról beszélsz. Gondolom az a bajod, hogy egy kis egyablakos Hello World!" is súlyos 10MB-okat zabál fel, pedig neked nincs szükséged arra a sokmindenre, ami ennyit zabál.

    Két dologra kell gondolnod:

    1) A Delphi programok (GUI-s program esetén) magával cipelik szinte majdnem az egész VCL-t. Ezért lesz egy Hello World! is bazi nagy. És te attól tartasz, hogy a programod lineáris méretnövekedése szintén lineáris memóriazabálással fog növekedni. Hát nem. Mivel a VCL alapból rendelkezésedre áll, így a programod növekedésével tényleg csak annyit fog nőni a memóriaigény, amennyit a saját programod megzabál. Azaz az a 10MB alapból felzabált memória az úgymond fix, se több, se kevesebb, az mindig ott van a Delphi GUI-s programokban. De efölött már nem 10MB-onként fog nőni a program memóriaigénye, hanem tényleg csak attól függ majd, hogy te, mint programozó, mennyire bánsz kesztyűs kézzel a memóriát illetően.

    2) Nem az OOP miatt zabál a Delphi. Bár igaz, hogy a virtuális osztály/metódus táblái memóriát igényelnek, de ez elenyészően kicsi, és csak a táblák mérete az, ami drasztikusan nőhet, nem maga az OOP működési mechanizmusa növeli azt meg. Az OOP csak egy paradigma, vagyis amolyan programozói filozófia, nem pedig konkrét memóriazabáló dolog. Sok esetben igaz, hogy strukturáltan megírt kód sokkal több memóriát eszik, mint ugyanaz OOP-ben, jól átgondolt osztály-hirearchiával.


    Megjegyzés: A VCL-féle több 10MB-ot az csak hasra ütve mondtam, csak a szemléltetés volt a célom.
    Mutasd a teljes hozzászólást!
  • Nem értem, mi bajod van a rammal... Ha egyszer már ott van az adat a ramban, akkor a processzor onnan mar jo gyorsan el tudja érni és nem kell kerregtetnie a két 10 éves winyómat sem.
    En inkabb attol leszek ideges, hogy a win bármikor gondol egyet és 5 percig kerregteti a swapfile-t (na emiatt le is lett tiltva)

    Az "5millió úgy jópárszor fölösleges tulajdonsággal" rendelkezo ojjektumokrol: Minek irsz ilyen ojjektumokat, fizetnek érte? :D


    "hogy mit is kell csinalni azzal a szovegfajllal" <- ez le lett irva: be kell olvasni
    Mutasd a teljes hozzászólást!
  • Az kerdesedre a valasz az adott feladattol fugg (hogy mit is kell csinalni azzal a szovegfajllal).

    ...egy komponens mindent tud...

    "Nem akkor alkottál tökéleteset, ha már nem tudsz mit hozzátenni, hanem ha már nem tudsz mit elvenni belőle."
    Mutasd a teljes hozzászólást!
  • pl ez az objectumorientált programozás dolog vagy annak a címén úgy látom kicsit túlzottan elment abban az irányban pl egy komponens mindent tud (kivéve főzni és vasalni) de 5millió úgy jópárszor fölösleges tulajdonsággal, ami fölöslegesen terheti a gépeket, ált a memóriát

    magánál a ramnál? hát csupán aza kérdés biztosan azt akarjuk-e hogy egy adatot tegnapra akarunk-e... mintha lenne idő földolgozni és megnézni mindet...

    amúgyeza dolog kicsit arra célozna nálam ok hogy az op.rsz elintézi hogy swap meg ezek, de talán mégis kéne nekünk is óvatosabban használni az erőforrásokat

    szóval még várom az 5leteket, ill. ki hogyan látja miaza határ aminél azt gondolja ő x% ezt használja y% ezt

    aki 100% memóriára szavaz csakegy tipp: nem kell kikapcsolni a gépet és nem kell winchester a gépbe: kb 20Mszorosa a memóriának mint használt adatoknak elég lesz
    Mutasd a teljes hozzászólást!
  • naezt szeretném elkerülni, ugyanis igen ez a dolog nemigazán van ínyemre és amint tehetem más megoldás után nézek


    Mire gondolsz?

    Mit tudsz mondani ami ramnal hatekonyabb?
    Mutasd a teljes hozzászólást!
  • ezzel a mindent a memóriába dologgal csak az a baj hogy ha ez így halad az 1Tb memória is kevés lesz
    csak egy ismertebb példa: jelenleg az egyik böngésző telepítője ~10Mb használat során méghacsak 1 lap is van nyitva ez 100M
    naezt szeretném elkerülni, ugyanis igen ez a dolog nemigazán van ínyemre és amint tehetem más megoldás után nézek
    de aszem ezzel nem leszek egyedül
    Mutasd a teljes hozzászólást!
  • Összefoglalva: Ha a feldolgozandó állomány elfér a virtuális memóriában, akkor mindenképpen beolvasnám, legfeljebb a rendszer egy részét száműzi a swap-ra. Ha meg nem fér el, akkor úgy sincs választásom...


    A teljesség kedvéért: van egy harmadik lehetőség is, a memory mapping. (Linux alatt az "mmap" függvénynek kell utánanézni, Windows alatt MapViewOfFile a függvény neve.) Ilyenkor a processzednek úgy tűnik, hogy a fájl végig a memóriában van, de valójában az oprendszer automatikusan olvassa be a memóriába, amikor hozzá akarsz férni egy részéhez, illetve kitörli a memóriából a régen nem használt részeket. Nem csodaszer persze, de bizonyos feladatokat kényelmesebb ezzel megoldani, mint manuális olvasással.
    Mutasd a teljes hozzászólást!
  • Az operációs rendszerek használnak egy swap-területet a merevlemezen. (Ez a linuxnál külön partíció, Windows esetén pedig a C: része.)

    Ha megtelik a memória, a ritkán használt cuccokat ide írják ki belőle. Ha te beemelsz egy jó nagy fájlt a memóriába, és ott van neki helye, az jó. Ha nincs, akkor az op.rendszer kiírja a felesleges dolgokat a swap-ra, ami nem rosszabb annál, mint amikor a merevlemezről olvastad be a fájlt.
    Tehát én inkább a memóriában végeznék I/O műveleteket, mint a merevlemezen.
    Előfordulhat az is, hogy akkora állományt akarsz beolvasni, ami sem a memóriában, sem a swap-en nem fér el. Ilyenkor sok választásod nincs, a programod nem tud elég memóriát foglalni magának, és kénytelen vagy a merevlemezről olvasgatni.

    Összefoglalva: Ha a feldolgozandó állomány elfér a virtuális memóriában, akkor mindenképpen beolvasnám, legfeljebb a rendszer egy részét száműzi a swap-ra. Ha meg nem fér el, akkor úgy sincs választásom...
    Mutasd a teljes hozzászólást!
  • Hello!

    A kérdésem:
    Mi az az optimális arány amit egy program adatok olvasása során a merevlemezből vagy a memóriából kell olvasson ezt hogyan támogatja az operációs rendszer?
    Példában szerepeljen egy közepes méretű szöveges fájlt
    Nem a kézenfekvő megolvás hanem a leginkább erőforrás és memóriahasználat-kímélő megoldás érdekel.
    És ez hogyan függ egy gép konfigjától?
    Kihegyezve érdekel PII->PIII gépre ajánlott arányok
    64->500M memórával
    Windows op. rsz (98->XP)
    Delphi programozás
    PHP szerver oldali nyelv esetén

    köszönöm
    Mutasd a teljes hozzászólást!
abcd