A lidR és a lasR csomag benchmarkja

A lidR és a lasR csomag benchmarkja Kézirat (TKP2021-NVA-13) Tóth Zsolt 2025 Tartalomjegyzék Bevezetés 1 1. Szakirodalmi áttekintés 1 2. Adatok és módszer 2 2.1. Mitérdemesmérni? ......................................... 2 2.1.1. A számítógépes teljesítménymérés lehetséges dimenziói . . . . . . . . . . . . . . . . . . 2 2.1.2. Afutásiidő.......................................... 2 2.1.3. Memóriahasználat ...................................... 3 2.1.4. A mélyebb mérőszámok nélkülözhetősége . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Amérésifolyamat .......................................... 4 2.2.1. Adatforrásésformátum ................................... 4 2.2.2. Mérésciklusokkal....................................... 4 2.2.3. Benchmarkprotokoll ..................................... 4 2.2.4. Kiértékelés .......................................... 5 2.3. A mérés konkrét megvalósításának sémája . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1. Munkakönyvtár beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.2. Csomag betöltése és beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.3. Tesztfájlelérése........................................ 6 2.3.4. Benchmarkciklus (100+2 ismétlés) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.5. Mentés ............................................ 6 2.3.6. Futtatás............................................ 7 2.4. Afuttatókörnyezetjellemzői..................................... 7 2.5. Azösszehasonlításmódszerei .................................... 7 2.5.1. Két időmérési módszer előtesztelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5.2. Két memória-csúcshasználatot mérő módszer előtesztelése . . . . . . . . . . . . . . . . 9 2.5.3. Fájlbetöltés lidr-ben és lasR-ben ............................. 9 2.5.4. Teljes elemzési pipeline összehasonlítása . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.5. Egy output-művelet összehasonlítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Eredmények 13 3.1. A két sebességmérési módszer értékelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. A két memória-csúcshasználatot mérő módszer értékelése . . . . . . . . . . . . . . . . . . . . 14 3.3. A fájlbetöltés összehasonlítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Teljes elemzési pipeline összehasonlításának eredményei . . . . . . . . . . . . . . . . . . . . . 16 3.5. Az output-művelet összehasonlításának eredményei . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Összefoglalás 17 Köszönetnyilvánítás 19 Hivatkozások 20 Bevezetés A korábbi kutatások alapján megállapítottuk, hogy tudományos szempontból a lidR [9] és a lasR [8] összehasonlítása tűnik a legizgalmasabbnak és a legfontosabbnak. A LiDAR-adatok feldolgozásában két meghatározó C++ alapú R-csomag teljesítményének összehasonlítása eddig nem történt meg statisztikailag megbízható módon. Kutatásunk célja ennek pótlása, természetesen a teljesesség igénye nélkül, néhány fontos pontra koncentrálva. AlidR és a lasR benchmarkingja azért adja a legnagyobb tudományos értéket, mert a két csomag ugyanazt a feladatkört célozza, de eltérő technológiai megközelítést alkalmaz. A lidR stabil, széles körben használt, R-alapú környezetben működik, C++ alapokon, és jól illeszkedik a tudományos elemzésekhez, különösen erdészeti alkalmazásokban. Ezzel szemben a lasR egy új, nagy teljesítményű könyvtár, amely szintén C++ motorra épül, és kifejezetten nagy adathalmazok gyors feldolgozására optimalizált. Felmerülhet még a Python-környezetben való elemzés is, de ez jó eséllyel nem ad új információt a két C++ motor hatékonyságáról. Az összehasonlítás lehetőséget ad arra, hogy feltárjuk a két megközelítés közötti különbségeket sebesség, memóriahasználat és algoritmikus hatékonyság tekintetében, ami kulcsfontosságú a jövőbeli feldolgozási stratégiák meghatározásához, különösen akkor, ha a LiDAR-adatok mennyisége tovább növekszik. A többi csomag más fókuszú: a LAStools és a PDAL inkább ipari és parancssoros megoldások, a WhiteboxTools és az Orfeo ToolBox GISés távérzékelési platformok, a PCL és a CloudCompare pedig 3D-s és robotikai orientációjú eszközök, míg a libLAS elavult és csak fájlkezelésre alkalmas. Ezért a lidR és lasR összevetése nemcsak a jelenlegi standard és a potenciális jövőbeli alternatíva közötti különbségeket tárja fel, hanem irányt mutat a nagy adathalmazok feldolgozására optimalizált módszerek kiválasztásában. Elemzésünk futási idő és memória-csúcshasználat alapján ad statisztikailag megalapozott összehasonlítást. 1. Szakirodalmi áttekintés AlidR és a lasR teljesítményének összehasonlítása a lasR viszonylagos újszerűsége miatt a szakirodalomban rendkívül szórványos, tudományos igényű benchmarkot eddig nem publikáltak. Általánosságban elmondható, hogy a témával foglalkozó kutatók a lidR-t hatékonynak tartják a légi LiDAR-adatok manipulálására és vizualizálására, főleg erdészeti alkalmazásokban. Az lasR-t pedig nagy teljesítményű változatnak tartják. [6] A két csomag egy kutatásban való használatára találunk példát a lombkoronaszerkezet-elemzésben [2], a boreális tájak hóvastagságának és hóvíz-egyenértékének felmérésében [16], a fák növekedési ütemének meghatározásában [5], illetve a különböző Structure-from-Motion (SfM) algoritmusparaméterek és az egyedi fadetektálás pontossága közötti kapcsolat elemzésében [15]. A cloud2trees csomag keretében már a két csomag egyesített verzióját is használták a lombkoronaszint nedvességtartalmának elemzése során, amely azonban teljesítményproblémákkal járhat [3]. A tudományos tapasztalatok és a kapcsolódó dokumentáció alapján elég pontosan kirajzolódik a két csomag közötti különbség (1. táblázat). A két csomag tudományos igényű benchmarkjára a szakirodalomban nincs példa, de a szerző tudományos múltja [12–14] és a reprodukálható kód alapján egy viszonylag megbízható benchmarkra találtunk példát [10]. A szerző a lasR és a lidR csomagok teljesítményét hasonlította össze különböző LiDAR-feldolgozási feladatokban (pl. DTM, CHM, normalizálás, fahely-azonosítás). A benchmarkok 204 millió pontból álló, 20 km²-es területet lefedő adatállományon futottak Linux környezetben. Az eredmények szerint a lasR lényegesen hatékonyabb, mert: • A lasR C++ szinten, egyetlen adatbeolvasással végzi a teljes pipeline-t, míg a lidR többször olvassa be a fájlokat, ami jelentős időés memóriaigényt okoz. • A lasR natívan támogatja a többmagos feldolgozást, míg a lidR külső csomagokra (pl. future) támaszkodik. 1 • A több lépésből álló folyamatok (pl. normalizálás, DTM/CHM előállítás, fahely-szegmentálás) lasRben egyetlen pipeline-ban futnak, ami nagyságrendekkel gyorsabb és skálázhatóbb, akár több száz fájlra is. A szerző szerint a nagy kiterjedésű LiDAR-adatok feldolgozására a lasR sokkal alkalmasabb, mint a lidR. Bár a fenti megállapítások vélelmezhetően helyesek, óvatosan kell azokat fogadnunk. A benchmark a közölt kód alapján [7] valószínűleg a nagy adathalmaz és a hosszú, néhány esetben akár kétórás futásidő miatt minden mérést csak egyszer végzett el. A kód célja tehát inkább demonstráció, nem statisztikai összehasonlítás volt. 1. táblázat: lidR és lasR csomagok összehasonlítása Jellemző lidR lasR Nyelv/környezet R (C++ motorral) C++ (R és Python API) Megbízhatóság Stabil Fejlesztési fázisban Teljesítmény Közepes sebesség Kimagasló sebesség Adatméret Kis és közepes méretű adathalmazokra optimalizált Nagy adathalmazok (akár terabájtok) hatékony kezelése Fő funkciók LAS/LAZ beolvasás, CHM, DTM, fák szegmentálása Pipeline-ok, optimalizált algoritmusok, javított többmagos feldolgozás Licenc GPL-3 GPL-3 Tudományos alkalmazás Széleskörű, erdészeti kutatásokban elterjedt Szórványos, de ígéretes 2. Adatok és módszer Cikkünkben kisebb adatállomány mellett, statisztikailag megbízhatóbb módon fogjuk a korábban hivatkozott benchmarkot [10] néhány fontos elemre koncentrálva elvégezni. 2.1. Mit érdemes mérni? 2.1.1. A számítógépes teljesítménymérés lehetséges dimenziói A számítógépes rendszerek teljesítményének kvantitatív értékelése összetett feladat, amelyben számos különböző tényezőt lehet mérni és elemezni. A modern hardverek rétegzett felépítése, a fordító optimalizációi, a memóriarendszer komplex viselkedése és az operációs rendszer által végzett ütemezési, allokációs és háttérfolyamat-kezelési mechanizmusok mind befolyásolják egy program vagy függvény futási tulajdonságait. Ennek megfelelően a benchmarkolásban potenciálisan rendkívül sokféle mutató vizsgálható: többek között a CPU-idő, a falióraidő, a párhuzamos szálak kihasználtsága, a memóriaműveletek száma, a cache-hatékonyság, a branch prediction pontossága, az utasításszintű párhuzamosítás (ILP) mértéke, a memóriasávszélességre gyakorolt terhelés, a rendszerhívások mennyisége, a háttérfolyamatok hatása, valamint a garbage collector működésének időigénye. Mindezek a tényezők valóban reális, gyakran jelentős hatással lehetnek a teljesítményre, és sok esetben a futási idő mögöttes okait kizárólag a mélyebb mutatók vizsgálata tárhatja fel. Bár szinte végtelen számú mérhető paraméter határozható meg, a gyakorlati teljesítményelemzésben két metrika emelkedik ki fundamentális jelentőséggel: a futási idő és a memóriahasználat. Ennek több, elméletileg és empirikusan is alátámasztható oka van, amelyek miatt a többi mutató – bármennyire értékes és részletes lehet is – elsősorban kiegészítő, másodlagos szerepet tölt be. 2.1.2. A futási idő A futási idő – legyen az CPU-idő vagy az általunk választott falióraidő – az egyetlen olyan teljesítménymérő, amely közvetlenül és azonnal megmutatja a felhasználó által érzékelt gyorsaságot. Míg az olyan mutatók, mint a cache-missek száma vagy az utasításszintű párhuzamosítás mértéke csak közvetett indikátorok, addig 2 a futási idő minden körülmények között abszolút eredmény: egy adott függvény vagy algoritmus tízszeres gyorsulása futási időben tízszeres tényleges teljesítménynövekedést jelent. Ráadásul a futási idő minden rendszerés nyelvi környezetben, minden hardveren és minden alkalmazási területen egységesen értelmezhető. A futási idő azért is kiemelten fontos, mert egyszerre integrálja a mögöttes alrendszerek teljesítményét: az I/O throughputot, a CPU mikroműveleteit, a memória-hozzáférési mintákat, a cache-használat hatékonyságát, a branch prediction működését, és a párhuzamos végrehajtás kihasználtságát. Ezáltal a futási idő olyan összegző mutató, amely implicit módon magában foglalja az összes többi mérhető folyamat részeredményét. Még ha a futási idő önmagában nem is mutatja meg pl. a lassulás konkrét okát, az eredmény szempontjából mindenképpen a legmegbízhatóbb és leguniverzálisabb mérőszám marad. 2.1.3. Memóriahasználat A másik fundamentális metrika a memóriahasználat, más néven RAM-foglalás vagy memória-csúcshasználat. A modern adatfeldolgozási feladatok – pl. R-ben, ahol a LiDAR állományok (pl. LAS/LAZ fájlok) milliós vagy nagyobb nagyságrendű pontfelhőket is tartalmazhatnak – tipikusan memóriaintenzívek. A memória a legszűkebb erőforrás sok elemzői környezetben: ha egy algoritmus nem fér el RAM-ban, akkor vagy nem fut le, vagy meghatározó mértékben lassul a lapozás (swap) aktiválása miatt. Így a memóriahasználat nem csupán egy teljesítménymutató a sok közül, hanem fizikai korlát, amely meghatározza a feldolgozható adatmennyiség felső határát. A memóriahasználat emellett egy algoritmus végrehajtási modelljére is fontos indikátor: megmutatja az adatszerkezetek hatékonyságát, az ideiglenes objektumok mennyiségét, a garbage collector terhelését és a chunk-alapú feldolgozások skálázódását. Mivel a legtöbb gyakorlati elemzői folyamat – így a lidR és a lasR csomagok működése is – közvetlenül függ a rendelkezésre álló RAM-tól, a memóriaigény is olyan univerzális és direkt mérőszám, amelyet a többi mutató csak árnyal, de nem helyettesít. 2.1.4. A mélyebb mérőszámok nélkülözhetősége A speciálisabb teljesítménymutatók – például a cache-hatékonyság, a branch missek, az utasításszám, a CPUmagok kihasználtsága vagy a memóriasávszélesség – kétségkívül értékesek az optimalizáció szempontjából. Ezek a mutatók azonban: 1. nem univerzálisak, mert architektúránként jelentősen eltérhetnek, 2. nem direkt mérőszámok, mivel nem feltétlenül korrelálnak lineárisan a teljes sebességgel, 3. nem integrált mutatók, tehát csak egy-egy részfolyamatot tükröznek, 4. nehezen interpretálhatók, különösen magas szintű nyelvekben (pl. R), ahol a tényleges végrehajtást gyakran a C/C++-ban vagy Fortranban írt belső függvények és a memóriakezelő rendszer is befolyásolja. Olyan összetett rendszereknél, mint a lidR vagy az lasR csomag, amelyek chunkolt feldolgozást, tömörített LAZ-dekódolást, fájlrendszeri I/O-t és többmagos végrehajtást kombinálnak, a mély hardvermutatók értelmezése különösen nehéz, és önmagukban ritkán adnak elegendő alapot a gyakorlati teljesítményértékeléshez. Végső soron a felhasználó vagy a kutató számára a teljesítménymérés célja általában nem az, hogy feltárja a processzorágak mikroszkopikus viselkedését, hanem az, hogy összehasonlítsa két algoritmus vagy két implementáció gyakorlati hatékonyságát. Ebben a kontextusban a kérdések tipikusan: • Melyik függvény fut gyorsabban? • Melyik igényel kevesebb memóriát? • Melyik „skálázódik” (sic!) jobban nagy adatmennyiségre? • Melyik illeszkedik egy adott hardver erőforrásaihoz? 3 Ezek a kérdések teljes mértékben megválaszolhatók a futási idő és a memóriahasználat alapján. Ha az egyik algoritmus kétszer olyan gyors és feleannyi memóriát igényel, akkor minden további mérőszám ellenére egyértelműen hatékonyabb. A mélyebb profilozási adatok leginkább a hibakeresés, a célzott optimalizáció és a holtpontok feltárása során értékesek, de a benchmarkolás fő kérdésére – az algoritmusok közti teljesítményviszonyokra – a két alapvető metrika már önmagában átfogó választ ad. 2.2. A mérési folyamat A LiDAR-adatok feldolgozása során az egyik kritikus lépés a pontfelhő fájlok (LAS/LAZ formátum) beolvasása. A beolvasási sebesség és memóriahasználat jelentősen befolyásolja a teljes feldolgozási pipeline hatékonyságát, különösen nagy kiterjedésű erdészeti vagy topográfiai adathalmazok esetén. A benchmarkolás célja, hogy kvantitatív mérőszámokat szolgáltasson a beolvasási művelet időigényéről és erőforrás-felhasználásáról. Ez a megközelítés illeszkedik a teljesítményértékelési gyakorlatokhoz, amelyeket a LiDAR-adatfeldolgozásban és a szoftverfejlesztésben alkalmaznak. 2.2.1. Adatforrás és formátum A benchmarkhoz standardizált LAS/LAZ fájlokat célszerű használni, mivel ezek az ASPRS által definiált formátumok, és széles körben alkalmazzák őket a légifelvételekből származó pontfelhők tárolására. A LAZ formátum tömörített, így a beolvasási sebesség és memóriahasználat összehasonlítása különösen releváns a gyakorlatban [1]. 2.2.2. Mérés ciklusokkal A mérés során adekvát módszer a megfelelő számú (𝑛 = 30…100) mérés ciklusokkal (iterációkkal) való elvégzése. A fő kérdés, hogy esetleg egy „külső” (pl. batch-) szkripttel tegyük ezt, vagy az adott nyelvi környezetbe (esetünkben R-be) ágyazva, úgymond belső ciklusként. A belső ciklus jobb választásnak tűnik. Ha külső ciklust alkalmaznánk (például külön R-sessionökben vagy különálló szkriptekben), a rendszer inicializálása, a csomagbetöltés és a fájlelérési overhead minden ismétlésnél újra megjelenne. Ez torzítaná a mérést, mert nem a beolvasási művelet tiszta idejét, hanem a környezeti overheadet is mérnénk. A belső ciklus ezzel szemben kontrollált környezetben ismétli a műveletet, így a variabilitás főként az I/O és memóriakezelésből származik. A belső ciklus lehetővé teszi, hogy azonos körülmények között (azonos hardver, szoftver, beállítások) gyűjtsünk nagy mintát (pl. 100 ismétlés). Ez statisztikailag megbízhatóbb átlagot/mediánt és szórást ad, mint ha külső ciklusban különböző állapotú rendszereket mérnénk, ahol a háttérfolyamatok és a cache-hatás eltérőek lehetnek. A belső ciklusban explicit módon törölhetjük az objektumot (pl. rm()) és futtathatjuk a garbage collectort (pl. gc()), így a memóriahasználat nem „halmozódik” fel. Külső ciklus esetén minden futás új R-sessiont igényelne, ami nehezebben kontrollálható, ráadásul lassabb. Az első néhány futás gyakran lassabb a cache és a rendszer optimalizációja miatt. Belső ciklusban ezt könnyen kezelhetjük (pl. első 2–3 mérés kizárása), míg külső ciklusban minden futás új „warm-up” lenne, ami torzítaná az eredményt. A belső ciklusban a fájl elérési útja és a rendszer I/O állapota állandó, így a mérés valóban az adott függvény teljesítményét tükrözi. Külső ciklusban a fájl megnyitása és a rendszer állapota jobban változhat. 2.2.3. Benchmarkprotokoll Ismétlések száma: Legalább 30–100 ismétlés javasolt a statisztikai stabilitás érdekében, mivel az első néhány futás „warm-up” hatással torzíthatja az eredményeket. 4 Időmérés: A beolvasási időt másodpercben vagy ezredmásodpercben kell mérni, a az adott művelet egész végrehajtási ideje során. Memóriahasználat: Nagy pontfelhők esetén folyamatos mérésigény is felmerülhet, az általunk használt kis pontfelhő esetén ez nem szükséges. Garbage collection: Az ismétlések között célszerű memóriatisztítást végezni, hogy minimalizáljuk a cachehatást. Hardver és szoftver dokumentálása: CPU, RAM, háttértár típusa, operációs rendszer. Párhuzamosítás: A szálak számának kontrollálását össze kell hangolni, mivel a párhuzamos feldolgozás jelentősen befolyásolhatja az eredményeket. Azonos környezet: A mérőkódokat parancssorosan futtatjuk, s ügyelünk a viszonylag azonos környezeti tényezőkre. 2.2.4. Kiértékelés Leíró statisztikák: Átlag, medián, szórás, minimum és maximum értékek. Előfeltételek: Paraméteres próbák esetén pl. normalitás vizsgálata. Outlierek kezelése: Az első néhány futás vagy egyéb kiugró érték kizárása indokolt lehet. Vizualizáció: Boxplot vagy hisztogram a futási idők eloszlásáról. Összehasonlítás: Különböző formátumok (LAS vs. LAZ), szálbeállítások, és attribútum-szelekció hatásának vizsgálata. A megfelelő próbák kiválasztása és használata. [4] 2.3. A mérés konkrét megvalósításának sémája Az mérés általános folyamatát egy olyan mérési folyamaton keresztül mutatjuk be, amely lépésről lépésre leírja a folyamatot, s kisebb-nagyobb változtatásokkal az összes folyamatnál érvényes. A lenti kódrészlet egy benchmarktesztet futtat a lidR csomagban található readLAS() függvényre, amely LiDAR pontfelhő fájlokat olvas be. 2.3.1. Munkakönyvtár beállítása A lenti könyvtár lesz az alapértelmezett hely a fájlok mentéséhez. setwd("[A konkrét könyvtár neve]") 2.3.2. Csomag betöltése és beállítások A kódrészlet az alábbi feladatokat végzi el: •lidR betöltése LiDAR feldolgozáshoz. • Kikapcsolja a progress bar-t. • Egyetlen szálon futtatja a műveleteket (benchmark céljából). Kis pontfelhők esetén a szálak mennyiségének nincs valós hatása a futás sebességre. suppressPackageStartupMessages({ library(lidR) options(lidR.progress = FALSE) }) set_lidr_threads(1) 5 2.3.3. Tesztfájl elérése A benchmark statisztikai megbízhatóságának biztosításához több futásra (𝑛 = 100) van szükség minden esetben. Ezért a lidR csomagba beépített Topography.laz fálj használjuk kiindulópontként. laz_path <- system.file("extdata","Topography.laz",package = "lidR") A csomag adataiból jól látható, hogy viszonylag kis pontfelhőről van szó. Ez azonban számos, „hétköznapi” tudományos feladathoz közelebb áll, illetve a sorozatos méréseket is lehetővé teszi. ## class : LAS (v1.2 format 1) ## memory : 3.6 Mb ## extent : 273357.1, 273642.9, 5274357, 5274643 (xmin, xmax, ymin, ymax) ## coord. ref. : NAD83(CSRS) / MTM zone 7 ## area : 68728 m² ## points : 73.4 thousand points ## type : airborne ## density : 1.07 points/m² ## density : 0.78 pulses/m² 2.3.4. Benchmarkciklus (100+2 ismétlés) A kód „lelke” az alábbi feladatokért felelős: • A „warm-up” szakaszt a legtöbb, elvben kifinomultabb R-mérőeszközhöz hasonlóan két futtatásban határozták meg, ezért az ismétlések száma 𝑛 = 102. • Minden beolvasás idejét ezredmásodpercben mér. • Az objektumot törli és futtatja a garbage collectort. n<- 102L elapsed_ms <- numeric(n) for (i in seq_len(n)) { t0 <- Sys.time() suppressWarnings(suppressMessages( invisible(capture.output({ las <- readLAS(laz_path) }))) ) t1 <- Sys.time() elapsed_ms[i] <- as.numeric(difftime(t1, t0, units = "secs")) *1000 rm(las); gc(verbose = FALSE) } 2.3.5. Mentés A kód utolsó szakaszában: • A LAS-objektumot egy globális változóba töltjük. • Az utolsó beolvasott LAS-objektumot elmentjük RData formátumban. • Az első két mérés kihagyásával („warm-up”) a 100 időmérés eredményét elmentjük egy CSV-fájlba. las <- readLAS(laz_path) save(las, file = "las.RData") write.csv(data.frame(elapsed_ms=elapsed_ms[3:102]),"readlas_time.csv") 6 2. táblázat. Alapvető környezeti jellemzők Tulajdonság Érték Operációs rendszer Microsoft Windows 11 Pro OS-verzió 10.0.26200 CPU-modell 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz CPU-magok (Cores) 2 CPU-szálak (Threads) 4 Max. órajel (GHz) 3 Teljes RAM (GB) 7,73 2.3.6. Futtatás Az egyes kódok futtatása során rendkívül egyszerű módszert választottunk: az R-kódokat parancssorosan, Rscript segítségével futtatjuk. Az Rscript parancssori futtatás biztosítja, hogy minden mérési fájl külön R sessionben induljon, így elkerülhető a memóriaállapot és objektumok áthúzódása az egymást követő futások között. Ez növeli a mérés reprodukálhatóságát és csökkenti a környezeti torzító tényezőket. A parancssori futtatás minimalizálja az interaktív környezet (pl. RStudio) által okozott overheadet, amely magában foglalhat grafikus felülethez kapcsolódó folyamatokat és háttérfigyeléseket. A futtatás során batchfájlok is használhatók lennének, de ezt az alternatívát elvetettük. A batchfájl futtatása növeli a kockázatát annak, hogy a futások között megmaradnak változók vagy állapotok. Az Rscript minden futtatásnál új R sessiont indít, így tisztább mérési környezetet biztosít. Az Rscript natív módon kezeli az R fájlokat, míg batchfájlban extra rétegek (pl. hívások, idézőjelek, PATH-beállítások) szükségesek, ami növeli a hibalehetőséget és az overheadet. 2.4. A futtatókörnyezet jellemzői A futtatókörnyezet legfontosabb jellemzőit a 2. táblázat mutatja. Látható, hogy egy meglehetősen átlagos, nagyjából bármelyik kutató számára elérhető konfigurációról van szó. 2.5. Az összehasonlítás módszerei 2.5.1. Két időmérési módszer előtesztelése A pontfelhő-feldolgozási feladatok során szükséges időbecsléshez a megfelelő algoritmus kiválasztása nagyon fontos. Ehhez a különböző algoritmusok teljesítményét kell összehasonlítanunk. A vizsgálat célja tehát annak meghatározása, hogy a későbbi mérésekhez melyik időmérési módszer alkalmazása indokolt. Ehhez két megközelítést teszteltünk azonos környezetben. Az első megoldást (2.3. fejezet) egyfajta alapsémaként már bemutattuk (a továbbiakban „A” módszer). A második eljárás a microbenchmark csomagot alkalmazza, amely nanomásodperc pontosságú mérést biztosít és automatikusan kezeli az ismétléseket, illetve alapértelmezés szerint két „warm-up” futást is biztosít (a továbbiakban „B” módszer). micro.bench <- microbenchmark( suppressWarnings(suppressMessages( invisible(capture.output({ las <- readLAS(laz_path) }))) ), times = 100 ) 7 55 60 65 70 75 80 85 90 Idő (ms) 1. ábra. A két mérési módszer összehasonlítása 3.2. A két memória-csúcshasználatot mérő módszer értékelése A mérés során – a bevezető „warm-up” után – a peakRAM::peakRAM() 4MB memória-csúcshasználatot mért minden egyes mérés során. Bár az időméréshez képest sokkal egységesebb eredményre számítottunk, a hibalehetőséget kizárva kontrollmérést is végeztünk, itt már néhány 4,1 MB-os érték is megjelent. Az eredmény nyilván egy tizedesjegyre kerekített, tehát a valós eredmény valahol 4MB körül lehetett. Sajnos a csomag pontosabb mérést nem tesz lehetővé. A profmem::profmem() függvény pontosabban, s szintén egységesen kb. 4MB „csúcs” RAM-ot mért (pontosabban: 3,99455261230469-et). Az eredmények látható egységessége miatt a statisztikai összehasonlítás ebben az esetben elhagyhatónak tűnik. Mindkét csomag egyformán alkalmasnak tűnik a mérésre. Azonban egy fontos stabilitási problémáról sem szabad megfeledkeznünk. Aprofmem::profmem() korábbi tapasztalataink szerint rendkívül pontos, hiszen valós időben és bájtszinten követi nyomon az összes memóriaallokációt. Ez – bár mi ezt most nem vizsgáltuk – lehetővé teszi a memóriagörbe részletes vizsgálatát, és akár több tizedesjegy pontossággal is meghatározható a csúcshasználat. Elméletben tehát ez ideális eszköz a pontos memóriaelemzéshez. A gyakorlat azonban mást mutat: hosszabb iterációk, ismétlődő olvasások vagy nagy adatfájlok esetén előfordulhat, hogy a profmem::profmem() belső struktúrája „elfogy” vagy egyszerűen nem rögzíti az új eseményeket. Ennek következménye, hogy a visszaadott adatkeret üres lesz, és a számított memória-csúcshasználat értéke nullára csökken. Ez a jelenség – bár nem a mérés elve hibás – visszatérő hibaforrásként jelentkezik, ami hosszabb benchmarkok vagy publikációk esetén súlyosan torzíthatja az eredményeket, és csökkenti a mérés reprodukálhatóságát. (Az első, még nem “hivatalos”, RStudio IDE-ből való futtatás során a hiba a mi esetünben is fellépett.) Ezzel szemben a peakRAM::peakRAM() sokkal stabilabb. Ez a függvény nem követ minden egyes allokációt, hanem a memória-csúcshasználatot közvetlenül, megbízhatóan méri. Ez azt jelenti, hogy még hosszabb iterációk során sem fordul elő az üres eredmény vagy a nullás csúcsérték. Az adat kimenete ugyan „csak” egy tizedesjegyre kerekítve jelenik meg, de a memóriamérési pontosság MB-skálán elegendő a legtöbb tudományos felhasználásra, különösen nagy fájlok és nagy számú iterációk esetén, de alapvetően kisebbeknél is. A kerekítés miatti apró eltérés (például 123,4MB versus 123,45MB) a mérés stabilitása és reprodukálhatósága szempontjából mellékesnek tekinthető. 14 Összességében, ha a cél egy egységes, stabil, reprodukálható és publikálható memóriabenchmark, akkor apeakRAM::peakRAM() használata tudományosan megalapozott döntés. Bár a profmem::profmem() precízebb, a gyakorlati instabilitása és a hosszabb iterációknál fellépő adatvesztés miatt nem nyújtja azt a reprodukálhatóságot, amely a tudományos alaposság egyik kulcsa. A peakRAM::peakRAM() biztosítja, hogy minden ismétlésből értékelhető adat szülessen, így a mérés következetes és megbízható marad, miközben a tizedesjegyek kerekítése nem jelent érdemi kompromisszumot a pontosság szempontjából. A későbbiekben használható statisztikai módszereket a választott peakRAM::peakRAM() függvényben alkalmazott kerekítés nem érinti. A memóriamérési eredmények egy tizedesjegyre történő kerekítése a gyakorlatban nem jelent érdemi problémát a későbbi statisztikai elemzések szempontjából. Ennek oka, hogy a mérésben fellépő abszolút kerekítési hiba – nagyjából 0,1 MB, vagyis hozzávetőleg 100 kB — nagyságrendekkel kisebb, mint maga a mérendő jel. A mérések természetes ingadozását az operációs rendszer memóriakezelése, a cache-ek állapota, az I/O-rendszer aktuális terhelése és az R garbage collectorának futási időzítése határozza meg; ezek együttesen rendszerint több megabájtos eltéréseket eredményeznek még azonos bemeneti adatok mellett is. Ehhez képest a kerekítés okozta eltérés elenyésző, és lényegében elvész a mérési zajban. Statisztikai szempontból a kerekítés hatása még kisebb. A kerekítési hiba szimmetrikus, ezért nagyobb elemszám esetén nem torzítja sem az átlagot, sem az eloszlás jellemzőit, és nem befolyásolja érdemben a variancia becslését. A relatív hiba regressziós modellekre, klaszterezési eljárásokra vagy bármely más elemzésre gyakorolt hatása statisztikailag elhanyagolható. A túlzott precizitás látszata gyakran amúgy is félrevezető lehet, hiszen a nagyobb tizedespontosság sem feltétlenül jelent megbízhatóbb mérést, a túlzottan részletezett értékeket sokszor a mérőeszköz saját bizonytalansága vagy instabilitása teszi illuzórikussá. 3.3. A fájlbetöltés összehasonlítása A 2.5.3. fejezet és a korábbi előtesztelés alapján látható, hogy a lidR használata gyors és közvetlen hozzáférést biztosít a LiDAR-fájlok adataihoz, ami különösen előnyös egy tudományos kutató számára, aki gyorsan szeretne statisztikai vagy alapinformációkat kinyerni a pontfelhőből. A lasR viszont rövid, gyors információk kinyerésére kevésbé kényelmes, mert a pipeline a beolvasás után nem ad vissza R-objektumot, s nem is lehet belőle az adatokat kinyerni. Afájlbetöltés →gyors információk kinyerése →az objektum elraktározása későbbi felhasználásra a tudományos kutatás kezdeti szakaszában elég gyakori, ismétlődő pipeline, de ezt a lehetőséget csak a lidR biztosítja. AlidR-hez (2.5.1. fejezet) és a lasR-hez kapcsolódó összetett módszer (2.5.3. fejezet) már lehetőséget teremt a futási idő és a memória-csúcshasználat összehasonlítására. A futási időben a lasR („B”) pipeline-megközelítése drámai futásidő-növekedést okozott. ## Outlierek száma A-ban: 7 ## Outlierek száma B-ben: 11 ## N Átlag Szórás Medián Minimum Maximum ## A 100 56,24328 1,279456 55,90641 55,11904 64,03399 ## B 100 165,68246 12,909377 162,23204 153,51295 252,45500 ## Shapiro A: p=2.071e-14, Shapiro B: p=8.605e-16 ## Fligner: p=4.103e-17 ## ## Wilcoxon rank sum test with continuity correction ## ## data: A and B ## W = 0, p-value < 2,2e-16 ## alternative hypothesis: true location shift is not equal to 0 ## ## Rank-biserial r = 2.0100 15 ## Cohen's d = -11.9305 Kijelenthető, hogy a lasR időmérési módszere jóval kevésbé hatékony ebben az esetben. A memória-csúcshasználatban a különbség kisebb, de ott is számottevő. (Mivel a memóriahasználat a két adatsorban rendre azonos volt, a számítások nagy része elhagyható.) ## N Átlag ## A 100 4,0 ## B 100 5,4 AlidR tehát a fájlbeolvasási feladat memória-csúcshasználati eredményei alapján is hatékonyabb, mint alasR‘. 3.4. Teljes elemzési pipeline összehasonlításának eredményei AlidR pipeline-szerű („A”) és a lasR („B”) pipeline-időmérésének összehasonlítása: ## Outlierek száma A-ban: 1 ## Outlierek száma B-ben: 1 ## N Átlag Szórás Medián Minimum Maximum ## A 30 9040.4814 227.91469 8945.9524 8781.910 9784.1251 ## B 30 465.1288 17.82927 463.9406 443.697 547.5841 ## Shapiro A: p=0.0009922, Shapiro B: p=3.483e-07 ## Fligner: p=2.977e-07 ## ## Wilcoxon rank sum exact test ## ## data: A and B ## W = 900, p-value < 2.2e-16 ## alternative hypothesis: true location shift is not equal to 0 ## ## Rank-biserial r = 0.0333 ## Cohen's d = 53.0481 Az összehasonlítás egyértelműen azt mutatja, hogy a két vizsgált megoldás teljesítménye között rendkívül nagy különbség van. A lasR-alapú feldolgozás lényegesen gyorsabb és stabilabb, míg a lidR-alapú megközelítés sokkal hosszabb futási időt igényel. A statisztikai vizsgálatok szerint a különbség nemcsak szignifikáns, hanem gyakorlati szempontból is kiemelkedő, ami egyértelműen a lasR-pipeline előnyét jelzi. AlidR pipeline-szerű („A”) és a lasR („B”) pipeline-csúcsmemóriamérésének összehasonlítása az alábbiakban látható. Mivel a „warm-up” szakasz után mind a 30 mérés mindkét esetben rendre azonos értéket mutatott, a számítások többségét elhagyjuk. ## N Átlag ## A 30 29,9 ## B 30 7,5 AlidR-ben felépített pipeline a lasR pipeline-hoz képest jóval több memóriát igényelt. A lasR tehát ebben az esetben a memória-csúcshasználatban is hatékonyabb volt. 3.5. Az output-művelet összehasonlításának eredményei AlidR („A”) és a lasR („B”) plotkiírási időmérésének összehasonlítása: ## Outlierek száma A-ban: 4 16 ## Outlierek száma B-ben: 1 ## N Átlag Szórás Medián Minimum Maximum ## A 30 1934.4907 34.669858 1921.137 1911.5009 2026.4330 ## B 30 280.8953 7.280911 279.700 274.9851 317.2951 ## Shapiro A: p=4.771e-08, Shapiro B: p=3.565e-09 ## Fligner: p=0.0001972 ## ## Wilcoxon rank sum exact test ## ## data: A and B ## W = 900, p-value < 2.2e-16 ## alternative hypothesis: true location shift is not equal to 0 ## ## Rank-biserial r = 0.0333 ## Cohen's d = 66.0116 Az első, lidR-re épülő módszer lényegesen lassabb és nagyobb szórást mutat, míg a második lasR-ben megvalósított módszer sokkal gyorsabb és stabilabb. Mindkét eloszlás erősen eltér a normalitástól, és a szórások sem azonosak, ezért nemparaméteres összehasonlítás indokolt. Az eredmények szerint a két eljárás közötti különbség rendkívül szignifikáns, a hatásméret pedig rendkívül nagy, ami egyértelműen a második módszer gyakorlati fölényét jelzi. Az első módszer tehát nem versenyképes sebesség szempontjából, míg a második megbízható és hatékony választás a feladathoz. AlidR („A”) és a lasR („B”) plotkiírási csúcsmemória-mérésének összehasonlítása az alábbiakban látható. Mivel a „warm-up” szakasz után mind a 30 mérés mindkét esetben rendre azonos értéket mutatott, a számítások többségét elhagyjuk. ## N Átlag ## A 30 5.2 ## B 30 1.8 A plotkiírási feladatban a lidR sokkal rosszabbul teljesített, a lasR-hez képest mintegy háromszoros értéket mutatott a memória-csúcshasználatban. Az eljárások végén létrejövő hálózatos térdiagram a 2. ábrán látható. 4. Összefoglalás A kutatás célja a lidR és a lasR csomagok teljesítményének összehasonlítása volt LiDAR-adatok feldolgozása során, különös tekintettel a futási időre és a memóriahasználatra. A vizsgálat statisztikailag megalapozott benchmark-protokollt alkalmazott, amely ismételt mérésekkel és előtesztelésekkel biztosította az eredmények megbízhatóságát. Az elemzés kimutatta, hogy a fájlbeolvasási feladatokban és valószínűleg néhány kisebb, elkülönülő feladatban a lidR gyorsabb és rugalmasabb, ami előnyös az interaktív kutatási környezetben. Ezzel szemben a teljes feldolgozási pipeline és az output-műveletek esetében a lasR jelentős teljesítményelőnyt mutatott: nagyságrendekkel rövidebb futási időt és lényegesen alacsonyabb memóriaigényt igényelt. A lasR pipeline-alapú megközelítése különösen hatékony nagy adathalmazok kezelésében, ami a jövőbeli LiDARfeldolgozási stratégiák szempontjából kulcsfontosságú. Összességében megállapítható, hogy kisebb, gyors elemzést igénylő feladatokhoz a lidR továbbra is megfelelő választás, míg nagyobb, komplex feldolgozási folyamatokhoz a lasR kínálja a legjobb teljesítményt és skálázhatóságot. 17 273350 273400 273450 273500 273550 273600 273650 5274350 5274400 5274450 5274500 5274550 5274600 5274650 2. ábra. A benchmark során létrejött ábra 18 Köszönetnyilvánítás A publikáció a TKP2021-NVA-13 azonosítószámú projekt keretében a Kulturális és Innovációs Minisztérium Nemzeti Kutatási Fejlesztési és Innovációs Alapból nyújtott támogatásával, a TKP2021-NVA pályázati program finanszírozásában valósult meg. 19 Hivatkozások [1] 2 Reading, Querying & Validating – The lidR package.url: https://r-lidar.github.io/lidRbook/io.ht ml (elérés dátuma 2025. 11. 26.). [2] Darío Domingo és tsai. „Canopy Structural Changes in Black Pine Trees Affected by Pine Processionary Moth Using Drone-Derived Data”. en. Drones 8.3 (2024. márc.). Publisher: Multidisciplinary Digital Publishing Institute, 75. old. issn: 2504-446X. doi: 10.3390/drones8030075. url: https://www.mdpi .com/2504-446X/8/3/75 (elérés dátuma 2025. 11. 25.). [3] Lauren E. Lad és Camille Stevens-Rumann. To burn or not to burn: UAS mapping of tree-level foliar moisture content. Techn. jel. JFSP Project ID: 23-1-01-24. Joint Fire Science Program, 2024, 26. old. url: https://nrfirescience.org/resource/27559. [4] Chamin Nalinda Lokugam Hewage és tsai. „Scalability and Performance of LiDAR Point Cloud Data Management Systems: A State-of-the-Art Review”. en. Remote Sensing 14.20 (2022. jan.). Publisher: Multidisciplinary Digital Publishing Institute, 5277. old. issn: 2072-4292. doi: 10.3390/rs14205277. url: https://www.mdpi.com/2072-4292/14/20/5277 (elérés dátuma 2025. 11. 26.). [5] Maria Å Moan és tsai. „Detecting and excluding disturbed forest areas improves site index determination using bitemporal airborne laser scanner data”. Forestry: An International Journal of Forest Research 97.1 (2024. jan.), 48–58. old. issn: 0015-752X. doi: 10.1093/forestry/cpad025. url: https: //doi.org/10.1093/forestry/cpad025 (elérés dátuma 2025. 11. 25.). [6] Spencer O’Keeffe és tsai. „Leveraging Open-Source Tools to Analyse Ground-Based Forest LiDAR Data in South Australian Forests”. en. Remote Sensing 17.11 (2025. jan.). Publisher: Multidisciplinary Digital Publishing Institute, 1934. old. issn: 2072-4292. doi: 10.3390/rs17111934. url: https://www .mdpi.com/2072-4292/17/11/1934 (elérés dátuma 2025. 11. 25.). [7] r-lidar. lasR/vignettes/benchmarks.Rmd at main · r-lidar/lasR. en. url: https://github.com/r-lidar /lasR/blob/main/vignettes/benchmarks.Rmd (elérés dátuma 2025. 11. 26.). [8] r-lidar/lasR. original-date: 2023-11-29T19:16:56Z. 2025. nov. url: https://github.com/r-lidar/lasR (elérés dátuma 2025. 11. 23.). [9] r-lidar/lidR. original-date: 2016-02-17T11:47:38Z. 2025. nov. url: https://github.com/r-lidar/lidR (elérés dátuma 2025. 11. 22.). [10] Jean-Romain Roussel. Benchmarks of lasR vs. lidR. en-US. 2025. url: https://r-lidar.github.io/las R/articles/benchmarks.html (elérés dátuma 2025. 11. 23.). [11] Jean-Romain Roussel. Tutorial. en-US. url: https://r-lidar.github.io/lasR/articles/tutorial.html (elérés dátuma 2025. 11. 29.). [12] Jean-Romain Roussel és tsai. „Removing bias from LiDAR-based estimates of canopy height: Accounting for the effects of pulse density and footprint size”. Remote Sensing of Environment 198 (2017. szept.), 1–16. old. issn: 0034-4257. doi: 10.1016/j.rse.2017.05.032. url: https://www.sciencedirect.com/scien ce/article/pii/S0034425717302316 (elérés dátuma 2025. 11. 26.). [13] Jean-Romain Roussel és tsai. „lidR: An R package for analysis of Airborne Laser Scanning (ALS) data”. Remote Sensing of Environment 251 (2020. dec.), 112061. old. issn: 0034-4257. doi: 10.1016/j.rse.202 0.112061. url: https://www.sciencedirect.com/science/article/pii/S0034425720304314 (elérés dátuma 2025. 11. 26.). [14] André Soro és tsai. „The phenotypic and genetic effects of drought-induced stress on apical growth, ring width, wood density and biomass in white spruce seedlings”. en. New Forests 54.5 (2023. szept.), 789–811. old. issn: 1573-5095. doi: 10.1007/s11056-022-09939-5. url: https://doi.org/10.1007/s1105 6-022-09939-5 (elérés dátuma 2025. 11. 26.). [15] Wade T. Tinkham és George A. Woolsey. „Influence of Structure from Motion Algorithm Parameters on Metrics for Individual Tree Detection Accuracy and Precision”. en. Remote Sensing 16.20 (2024. jan.). Publisher: Multidisciplinary Digital Publishing Institute, 3844. old. issn: 2072-4292. doi: 10.3390/rs1 6203844. url: https://www.mdpi.com/2072-4292/16/20/3844 (elérés dátuma 2025. 11. 25.). [16] Maiju Ylönen és tsai. „UAV LiDAR surveys and machine learning improve snow depth and water equivalent estimates in boreal landscapes”. English. The Cryosphere 19.10 (2025. okt.). Publisher: Copernicus GmbH, 4585–4610. old. issn: 1994-0416. doi: 10.5194/tc-19-4585-2025. url: https://tc.c opernicus.org/articles/19/4585/2025/ (elérés dátuma 2025. 11. 25.). 20