and linux is not the only os.... I know of people injecting libraries between renders using LD_PRELOAD to monitor IO. But that is not going to work on osx (any more, without pain), and windows I don't have a clue about.
On 9 September 2016 at 12:56, Søren Ragsdale <[email protected]> wrote: > Is there a way to track this in the help of the kernel? /proc/<pid>/stat > will give you rchar (bytes of cached I/O read) and read_bytes (bytes > actually read from disk). > > Then again if you're doing all these reads inside a lightweight process or > with a special threading library this information might not be indicative of > what's going on, given that several reads could be occurring within the same > PID. All of which would be within the scope of whatever's calling OIIO, and > not OIIO's remit I suppose. > > On Thu, Sep 8, 2016 at 9:30 PM, Larry Gritz <[email protected]> wrote: >> >> Several of the underlying libraries allow you to inject your own methods >> to do the low-level I/O, but the problem is that they each have a >> *different* way of doing it, ugh. >> >> Making this work across all the file types would be a big job. >> >> >> > On Sep 8, 2016, at 6:22 AM, Chris Foster <[email protected]> wrote: >> > >> > On Wed, Sep 7, 2016 at 5:35 AM, Larry Gritz <[email protected]> wrote: >> >> But I don't think I can give any kind of accurate count of true I/O >> >> because >> >> I'm letting the underlying format libraries (such as libtiff or >> >> libIlmImf) >> >> handle all the decompression. Neither the TIFF nor OpenEXR libraries >> >> have a >> >> way for an app to find out the compressed size of a particular tile >> >> that is >> >> read, let alone also account for the fact that to read the tile, some >> >> amount >> >> (how much, exactly?) of other I/O is necessary to read headers, seek >> >> around, >> >> etc. >> > >> > A reasonable way to do this is to abstract away the underlying >> > filesystem IO operations into an object containing open, read, seek, >> > etc. There are other raster libraries which do this, gdal being an >> > example with its "virtual file system" abstraction. >> > >> > This would be an insanely huge job for the sake of a few stats, but >> > there's other interesting benefits. For example, if you're reading >> > texture from a cloud service like Amazon S3, being able to hit the S3 >> > API directly for texture data would be quite interesting. >> > >> > The more heavily used image libraries generally have a way to swap out >> > raw C IO functions for something custom in a reasonably >> > straightforward way (eg, I've done this for libjpeg before). For many >> > of the other plugins, I'm afraid it'd just be a big job... >> > >> > ~Chris >> > >> >> -- >> Larry Gritz >> [email protected] >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
