Android-14 telefon a sok fájlt (50e+) tartalmazó mappákat nagyon lassan kezeli.
Ugyanazt a mappát egy másik Android-8 telefon elfogadható sebességgel kezeli.
Próbáltam különféle teszteket mindkét telefonon, és PC-n is összehasonlításul.
Disk RD/WR [MByte/sec]: Android-14: 500/290; Android-8: 100/53; Laptop: 410/310
Vagyis ez alapján azt várnám , hogy az Android-14 legyen a leggyorsabb, de nem!
56000 fájlt tartalmazó directory lista beolvasása [sec]: Android-14: 6....17; Android-8: ~1; Laptop: 0.16
A 6...17 másodperc nem elírás! Van hogy 17 másodpercig tart, mire beolvassa a listát. Hogy mikor meddig tart az véletlenszerű.A többi eszköznél az első beolvasás lassabb, és a többi gyorsabb. Az Android-14 esetén lehet, hogy elsőre 6 sec, és közvetlenül utána megismételve 11 sec.
stat 56000 fájlon [sec]: Android-14: 0.08...0.8; Android-8: 0.1...0.18; Laptop: 0.06...0.22
10000 fájlt tartalmazó directory lista beolvasása [sec]: Android-14: 0.33; Android-8: 0.16; Laptop: 0.01
stat 10000 fájlon [sec]: Android-14: 0.01; Android-8: 0.1; Laptop: 0.01
Valami ötlet?
------------------------------------- kiegészítés 2025.03.25. 18:01
Az Android-14-en a fájlok áthelyezése is megdöbbentően lassan megy. kb 100 db fájl/másodperc
(Nem másolás! Áthelyezés egyik mappából a másikba.)
- 395 megtekintés
Hozzászólások
Szerintem ez a Linuxon is általában egy probléma, már annak, aki a Windowshoz szokott.
- A hozzászóláshoz be kell jelentkezni
Engem a reális use case érdekelne.
Aláírás _Franko_ miatt törölve.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
Ez a realis use casek foruma?! :D
- A hozzászóláshoz be kell jelentkezni
Az 56000 fájl egy angol hangos szótár. 11230 szó és mindegyikhez 4 db m3 hang.
- A hozzászóláshoz be kell jelentkezni
Szarul van strukturálva.
Aláírás _Franko_ miatt törölve.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
Nem szeretnék most arról vitatkozni, hogy hogyan írok programot. Már írtad, hogy tákolmány amit csinálok, most azt írod, hogy szar. Csak azt tudom erre mondani, jó neked, hogy ilyen okos vagy.
Megkérdezem most az okos embereket:
Ha kipróbáltam a témaindítóban leírt dolgot több Linuxon, egy Windowson és két Androidon, és ezek közül csak az Android-14 esetén van probléma. Pont azon az eszközön, aminek a lemez olvasási sebessége a teszteltek közül a legjobb (500 Mbyte/sec)? Nem elképzelhető, hogy az A-14 oprendszerrel van gond?
Nem lehet, hogy érdemes lenne esetleg nektek is megpróbálni, a közeletekben elérhető néhány gépen?
- A hozzászóláshoz be kell jelentkezni
A hasonló dolgokat úgy szokták mappákba rendezni (a fenti hibákat elkerülendő), hogy pl A-F, G-J, K-M .... stb mappákba rendezik, így nem kerül több tízezer fájl egy mappába.
Nem lehet, hogy érdemes lenne esetleg nektek is megpróbálni, a közeletekben elérhető néhány gépen?
Engem nem érint a probléma, mivel nem használom a szóban forgó szoftvert. Ez a userbase problémája (ami szerintem jelenleg kimerül benned), majd ők tesztelik.
Aláírás _Franko_ miatt törölve.
RIP Jákub.
neut @
- A hozzászóláshoz be kell jelentkezni
Sok évvel ezelőtt tanult kollégák alkalmazást akartak fejleszteni/venni az egy mappán belüli nagyon sok fájl (több száz ezer) kezelésére. A szkenner automatikusan gyártotta ezeket a fájlokat, értelmezve azokban a vonalkódot, ami alapján elnevezte őket. Kitűnő feladat az "imaging rendszer" beszerzésére (vagy fejlesztésére, már nem emlékszem pontosan). Az akkori aktuális Gizike figyelt, hallgatott és megjegyezte, nem érti minek. Ő Windowsban szocializálódott, beizzította a W7-et és a fájlkezelőben kattintásra kilistázta az egészet, sőt, keresett is benne mindenféle wildcarddal. Villanás alatt ment minden (pedig a SAMBA-n volt a mappa, gondolom automatikusan indexelt neki a windóz). Az Ubuntu simán eltöltött perceket ugyanezzel. Nagyon régen volt, lehet, hogy nem is W7, hanem még a nagytudású XP lehetett. Nem hiszem, hogy nagyon sokat változott volna ez, lehet megnézem mit szól egy ilyen feladathoz a Thunar vagy a Caja.
- A hozzászóláshoz be kell jelentkezni
"Az Ubuntu simán eltöltött perceket ugyanezzel."
Fontos megkülönböztetni, hogy mi töltött el perceket, mert nem a Linux, hanem a fájlkezelő.
Én itt nem a fájlkezelő alkalmazásokról beszélek, hanem az oprendszerről.
A Linuxtól a Windowstól és más Androidoktól egy program a több tízezres listát tizedmásodpercek alatt megkapja.
- A hozzászóláshoz be kell jelentkezni
> nem a Linux, hanem a fájlkezelő.
> Én itt nem a fájlkezelő alkalmazásokról beszélek, hanem az oprendszerről.
Sajnos itt bukik ki, hogy valójában fogalmad sincs miről beszélsz.
Ha egy sima ls is perceket tökörészik rajta (gyanítom, hogy ez a helyzet amúgy), akkor bizony az oprendszer tölt el ennyi időt a fájlok fellistázásával. Ugyanis - és most fogok egy meglepőt mondani, kérek egy dobpergést - a fájlkezelők valójában nem külön entitások az oprendszer mellett, hanem az oprendszert használják a fájlok listázására.
Alapvetően a listázás kettő dolgot jelent ebben a kontextusban:
- A mappa tartalmának lekérdezését - ez atomi
- Minden egyes fájl metaadatainak lekérdezését - ez fájlonként atomi.
Ez utóbbira azért van szükség, hogy lásd pl a módosítás dátumát, a chmod-ot, a tulajdonost (ez szintén fájlonként +2 OS API hívás amúgy, ha nem csak ID-ket jelenítünk meg)
Több tízezer, vagy annál is több fájl esetén ez utóbbi lépés tud nagyon lassú lenni, mert egy nagyon sokelemű ciklus fut le, optimális esetben is minimum 1, de inkább 3-4 hívással. Még egyszer: ez teljesen független a fájlkezelőktől, egyszerűen maga az oprendszer így adja vissza a válaszokat.
Mentül lassabbak az egyes műveletek, és mentül több elemet kell lekérdezni, antul tovább tart az egész mappa tartalmának a listázása.
A Windows azért tud gyors lenni, mert a gyakran használt mappákat - hacsak teheti - agyoncacheli, így relatíve gyorsak a műveletek, főleg, ha nem másodpercenként többezer tartalom módosul az adott mappán belül. Ez nem teljesen az oprendszer érdeme - amennyire emlékszem, erre van külön szolgáltatás, de azt meg nem mondom, melyik. Mindenesetre mindegy is, mert Linuxon ilyen nincs, kernel szinten beépített semmiképpen.
Azért javasolják, hogy tördeld mappákra a fájljaidat, mert akkor kisebb lesz a fent említett ciklus, ráadásul gyorsabban is megfut, az alkalmazásodnak meg tökmindegy, mert +1 stringművelettel elő tudod állítani bármely fájl útvonalát - hiszen előre definiálható feltételek mentén alakítod ki a struktúrát, kvázi meg tudod "jósolni" mi lesz a fájl neve. Minimális munkával tudsz szignifikáns teljesítményjavulást elérni.
Tudod, jó dolog önállónak lenni, és jó dolog mindenféle kódokat írogatni, de nagyon érdemes mögénézni, hogy mikor mi történik a háttérben, és mit miért javasolnak emberek. Nem kell minden javaslatot megfogadni (ezt se itt fenn), de ha legalább azt megteszed, hogy utánanézel, hogy működik a rendszer ilyenkor, az sokszor rengeteget segít a különböző problémák felgöngyölítésében.
Azt a koncepciót meg felejtsd el, hogy van az oprendszer és van a mindenmás. Mivel minden az operációs rendszer felett fut, ezért a legtöbb alkalmazás teljesítményét alapvetően tudja befolyásolni az, ha oprendszer szinten valami adott módon működik. Nyilván erre még rájön az adott alkalmazás overheadje, ezért is érdemes egy adott problémát több irányból, több különböző alkalmazással tesztelni. Ha van közös metszet, akkor lehet gyanakodni, hogy az operációs rendszer a ludas a problémában.
- A hozzászóláshoz be kell jelentkezni
"Engem nem érint a probléma, mivel nem használom a szóban forgó szoftvert."
A szóban forgó szoftver az Android-14. Nem használod? Nem használja más csak én?
Nem kell használnod az én programomat. Írj valami saját kis tesztet!
- A hozzászóláshoz be kell jelentkezni
A szóban forgó sw nem az OS, hanem a te programod, ami a szokásos fájlmennyiséghez képest nagyságrendileg többet tárol egy könyvtárban. Nem ilyen use-case amire az adott fájlrendszert optimalizálták. Igen, fejlesztőként most jött el az ideje annak, hogy a fájlok kezelését refaktoráld, újragondold, vagy úgy, hogy saját indexet kreálsz a fájlokhoz (ha azok nem változnak), és ezt az indexet használd keresésre/listázásra, vagy az állományokat valamilyen elv alapján csoportosítva alkönyvtárakba rendezed, és ezeken keresztül kezeled az egészet.
A szituáció nekem arra a sztorira hajaz egyébként, amikor egy alkalmazás szakmányban f0sta a /tmp -be az átmeneti állományait minimális méretben ugyan, de számosság tekintetében szinte a csillagos ég volt a határ - és ezeket cron-ból próbálták takarítani a find használatával, fájlnév meg ctime/mtime/atime fene tudja melyiket vizsgálva. Na ez a find képes volt órákig molyolni, egymásra futni - gyakorlatilag nem működött. (Fentebb le lett írva, hogy egy könyvtár kezelése, listázása, fájlok kiválogatása fájlonként n darab rendszerhívás alapesetben). Megoldás az volt, hogy saját programmal könyvtár megnyit, végigolvas, névre mintát illeszt, ha az sikeres, akkor stat(), és ha a releváns időadata olyan, akkor unlink(). A legdurvább futási ideje is maximum percekben volt mérhető - igaz, ott Linux, meg VM, meg nem túl gyors tengelyes diszkekből összerakott FC-n elérhető storage volt alatta - pár millió állománnyal az ominózus könyvtárban...
- A hozzászóláshoz be kell jelentkezni
#szarazandroid, esetleg a konkrét gyártól által, a stock androidból taknyolt valami.
Nyilván érted, hogy adat-metaadat arányának romlásával arányosan kezdi elveszteni a jelentőségét, hogy mekkora a az adott "lemez" (ez már eleve lol) szekvenciális olvasási sebessége. Régen a ⸮kóklerek pl. .wad fájlokba tették az effélét. Ma sértődés van abból, ha nem tapsolnak, ha faszul csinál valaki valamit.
15-ös, stock Androidom van, ha ez segít, kipróbálhatom vele.
- A hozzászóláshoz be kell jelentkezni
Windows is elfárad pár 10k fájl felett. Ez ilyen, nem kell ennyi fájlt egy könyvtárban tartani.
- A hozzászóláshoz be kell jelentkezni
Én kipróbáltam több Linuxon, egy Windowson és két Androidon. Ezek közül csak az Android-14-en van vele probléma.
Te kipróbáltad, vagy csak tippeled?
- A hozzászóláshoz be kell jelentkezni
A Linux 0.16sec alatt olvassa be azt az 56000-es könyvtárlistát, amit az Android-14 6...17 másodperc alatt, és az Android-8 az 5-ször lassabb lemezzel is 1 sec alatt.
- A hozzászóláshoz be kell jelentkezni
#define "olvassa be"
Mert nagyon nem mindegy, ez számodra mit jelent...
- A hozzászóláshoz be kell jelentkezni
Számíthat, hogy milyen filerendszer? Eltérő OS eltérően kezelheti.
Számíthat a hálózat? Eltérő OS eltérő hálózati sebességet tudhat, szóba jöhet az MTU, illetve a protokoll verzióinak a sajátosságai.
Számíthat, hogy mi a tartalom? Lehet, hogy van valami párhuzamosan futó szolgáltatás, ami a beleolvas a fileokba, hogy ha képek akkor miniatűrökkel szórakoztathasson, vagy valami ilyesmi, és ezért lassabb.
Ha megoldható, és nem nagy munka, akkor érdemes lehet egy ekkora bejegyzés halmazt több alkönyvtárra bontani, például a file nevének első betűje szerint (ami nem túl hasznos ha DCIM* a fileok neve) de akkor meg lehet dátum szerint, vagy akármi, lévén fogalmunk sincs, milyen állományokról van szó.
- A hozzászóláshoz be kell jelentkezni
Androidos telefon és telefon közt hardverben sok különbség lehet ám.
- SoC tudása
- háttértár sebessége
- ha microsd kártyán vannak a fájlok, annak a sebessége
- ha microsd kártyán vannak a fájlok, lásd első pont
- ha usb-n éred el a fájlokat, az usb port sebessége
- a fentieken lévő fájlrendszer
- ha hálózaton át éred el a fájlokat, a wifi sebessége
- és ezeken kívül még a gyártó "optimalizálásai" az adott android rendszeren.
És akkor arról még nem beszéltünk, hogy nem mindegy, mivel nyitsz meg egy könyvtárat androidon, mert az egyik fájlkezelő minden megnyitásnál újraindexel, thumbnail-eket generál, exif adatokat olvas, különböző adatok szerint rendez. Még régebben futottam pl bele abba, hogy az "optimalizálás" érdekében a gyártó által az androidba integrált tisztító alkalmazás a háttérben futva automatikusan törölte a thumbnaileket a galéria bezárása után, hozzám csak azzal jöttek, miért ilyen lassú az a tetves képnézegető.
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. / "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993
- A hozzászóláshoz be kell jelentkezni
Tipp: az android 14 fs-ében a könyvtárbejegyzések esetleg láncolt listában vannak, ezért a keresés, módosítás O(n) idejű. (És egy teljes könyvtár kiürítése, átmozgatása, törlése O(n^2).) A Linux ext2 is küzdött ezzel, 20K könyvtárbeli bejegyzés fölött a file-törlés, listázás stb. kifejezetten lassú volt. Modernebb file-rendszerek valamilyen indexelést használnak a bejegyzések név szerinti felleléséhez, létrehozásához. Pl. ext3 és ext4 esetén van olyan filesystem feature, hogy "dir_index": "Use hashed b-trees to speed up name lookups in large directories. This feature is supported by ext3 and ext4 file systems, and is ignored by ext2 file systems" (man ext4).
Android 8-ról ekkora regresszió android 14-re mondjuk meglepő lenne...
- A hozzászóláshoz be kell jelentkezni
Ha Te írod a szoftvert és megállapítottad tesztekkel, hogy van olyan aktuális rendszer, ami a rendszer korlátai miatt lassan futtatja, akkor miért nem változtatsz a szoftveren/fájl struktúrán?
Értem, hogy Te adtál itt egy feladatot a népnek (mérje le mindenki ezt azon, amije van), és ha nem azt csinálják a hozzászólók amit kértél, akkor egyáltalán minek szóltak hozzá... De ez azért nem jó így (szerintem), mert Te már lemérted, hogy az Android 14 lassú, ergo nem lesz több információd azzal, ha ugyan ezt más is leméri.
Attól a szoftvered nem lesz gyorsabb, hogy még tíz ember leméri ugyanezt, hümmögünk rajta közösen, hogy hú, az Android 14 milyen szar az Android 8-hoz képest ezen a téren...
Te magad találtál egy olyan hibát, ami akuális eszközön gondot okoz a szoftverednek. Mivel az eszközöket nem tudod kijavítani, ezért javaslom a szoftver módosítását úgy, hogy ez a probléma ne okozzon gondot a használata során.
Példának a Kopia mentő szoftvert tudom felhozni, ami blokkokra bontva tárolja a mentéseket, minden blokknak van egy hash értéke, és a túl sok fájl per mappa elkerülésére a hash első 4 jegye egy mappa, másokdik 4 jegye azon belül egy almappa a többi jegye pedig ezen az almappán belül egy fájlnév. Nyilván azért alakították így ki, mert aránylag sok OS-en tapasztalták, hogy gondot okoz a túl sok fájl egy mappában. Ráadásul ez a szoftver engedi konfigurálni a bontás mélységét és az egyes szintekhez használt számjegyek számát, hogy a futtató rendszerhez legoptimálisabb elosztást meg lehessen keresni (akinek ilyenre van ideje és kedve).
- A hozzászóláshoz be kell jelentkezni
A Windows alatt sem mindegy hogy Bitlocker-rel vagy anélkül kezel fájlokat az ember. (Itt kifejezetten a nagyszámú fájlokat tartalmazó könyvtárak másolására gondolok) - Nem lehet.., hogy a 14-es Android már alapból titkosított fájlrendszert használ? (Mondjuk a 9-eshez képest?)
- A hozzászóláshoz be kell jelentkezni