Android-14 lassan kezeli a sok fájlt tartalmazó mappákat

Szerintem ez a Linuxon is általában egy probléma, már annak, aki a Windowshoz szokott.

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ó.

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ő.

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...

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 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?)

amelyik program ennyi fájlt egy mappában tárol, azt a programot törölni kell, mert annak a programnak a fejlesztője egyéb turpisságokra is képes

Szóval azt írod, hogy C proggival nézed (opendir+readdir+closedir), ami azért fontos, mert itt nincs plusz SYS_stat rendszerhívás, valamint ami még feltűnt, hogy azt írod, előfordul, hogy elsőre gyorsabb, mint másodjára.

Nézzük, mi történik ilyenkor a C programodban:
1. readdir libc-ben van implementálva, ez hívja a SYS_readdir syscall-t a kernelben
2. a kernel megnézi, szerepel-e a VFS dcache-ben, és ha igen, egyből visszaadja
3. ha nem szerepel, akkor végignyálazza a mount listet és továbbpasszolja a fájlrendszer meghajtónak (tényleg, milyen fájlrendszerről van szó?)
4. a fájlrendszermeghajtó megfelelő blokkokra bontja a kérést, és átpasszolja a blokkrétegnek
5. a blokkréteg megnézi, szerepel-e a blokk a struct buffer_head-ben, és ha igen, egyből visszaadja
6. ha nem, akkor továbbpasszolja a dev major/minor által kijelölt eszközmeghajtónak (gondolom SD kártya, tehát eMMC meghajtó vagy ilyesmi ebben az esetben, tehát /dev/mmcblkX)
7. itt blokkolódik a programod, amíg az eszközmeghajtó nem végez (ez adja a tényleges olvasási sebesség overheadjét)
8. amint beolvasódott a blokk, bekerül a buffer_head-be, majd onnan az fs rétegbe, onnan a VFS rétegbe a dcache-be, majd onnan a libc-be, és onnan a readdir visszatérési értékébe

Röviden, a nyers diszksebesség (7. pont) csak egyetlen egy, nem túl valószínű esetben számít (a legeslegelső híváskor). Mivel szekvenciális readdir hívásokról van szó, ezért a fájlrendszer hasítófák és hasonló baromságok (4. pont) semmit sem számítanak (az csak a namei() hívásnál gyorsít, itt nem). Szóval marad az, hogy valószínűleg nincs elég memória a dcache-nek (2. pont), ezért kell a második futásnál újra végigjárnia a teljes Canossa járást. Namost attól függően, hogy a bcache-ben benne van-e még (5. pont), megintcsak nagy lehet a szórás, mert ha benne van, akkor nem is kell a meghajtóhoz nyúlni és nem is blokkolódik a programod (kivéve, ha cache nélkül mountoltad, de ez nem valószínű, persze lehetséges.)

Ja, és mégegy fontos dolog: nagyon nem mindegy, hogy atime sync van-e vagy sem, mert ha van esetleg, akkor minden egyes dcache lekérés után végigmegy egy írási folyamat is (legalább a fájlrendszermeghajtó szintig, ami aztán dobhatja, ha az adott fs nem támogatja), míg ha ki van kacsolva az atime, akkor semmi sem történik.

Szóval én errefelé nézelődnék:
- ha flusholod a dcache-t (lásd itt), az számottevően befolyásolja-e a sebességet (ha nem, akkor szinte biztos, hogy nincs elég memória a kernel VFS-hez)
- milyen fájlrendszer van alatta, az kezel-e atime-ot
- milyen opciókkal lett felmountolva (van-e atime sync vagy esetleg write-thorugh és nincs egyáltalán cache (buffer_head) használva, ilyenek)

Remélem segít. Én mindenképp arrafelé nézelődnék, hogy második hívásnál miért nincs benne a struct dirent a VFS dcache-ben, szerintem itt lesz a kutya elásva. Simán lehet például, hogy a 14-esen fut valami másik proggi is, ami nyálazza a diszket (valami indexer pl.), és ami így folyton triggereli a LRU flush-t a dcache-ben, ezért a dirent-jeid folyton kikerülnek a memóriából. 8-ason viszont nem fut ilyen, így szépen ottmaradnak a memóriában.