<div dir="ltr"><div><br><br>On Thu, Mar 16, 2017 at 11:26 AM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>> wrote:<br>><br>[...]<br>><br>>>>> With the p1 tif and GRASS db on the same spinning HDD, and<br>>>>> 6 other heavy processes constantly reading from and writing to that same<br>>>>> HDD, r.in.gdal took 2h 13min to import the p1 tif. 360 MB as input and 1.5<br>>>>> GB as output is not that heavy on disk IO. Most of the time is spent<br>>>>> decompressing input and compressing output.<br>><br>><br>> Is it an 10000rpm disk?<br><br></div>I think you are on the wrong track, disk IO does not matter here. It was a 7200rpm disk, and the output of r.in.gdal was about 1.5 GB. It takes only seconds, not hours to write 1.5 GB to a HDD. <br><div><div><br>><br>>>> p2 is a harder one!<br>>><br>>><br>>> export GDAL_CACHEMAX=10000<br>>> gdal_translate -co "COMPRESS=LZW"<br>>> GHS_BUILT_LDS1990_GLOBE_R2016A_3857_38_v1_0_p2.tif p2_test.tif<br><br>> Also related?  GTIFF_DIRECT_IO, GTIFF_VIRTUAL_MEM_IO<br><br></div><div>Again, I think you are on the wrong track, disk IO does not matter here. And according to the GDAL documentation, GTIFF_DIRECT_IO, GTIFF_VIRTUAL_MEM_IO apply only to reading un-compressed TIFF
files.</div><div><br>><br>>> finishes in 28 minutes.<br>><br>> Impressive!<br><br></div><div>Hardware does not really matter here. To be precise, the difference between GDAL 1.11.4 and 2.1.3 is impressive, thanks to the efforts of the GDAL development team.<br></div><div><br></div><div>Regarding GDAL 2.1.3, profiling might tell why gdal_translate is so much faster than GRASS r.in.gdal.<br><br></div>Markus M<br></div></div>