Hi, thanks. Those tools might be good if it were a situation where a developer needs to do a one-time investigation with a special build, perhaps to trim down the memory consumption generally.
But actually, the use case I had in mind is for incorporating into detailed statistics available in the customer-delivered package. I can already give fairly accurate per-file counts for tiles read, time spent on I/O, memory held by my own code, etc., for each of the many thousands of image files accessed in a run. But the missing component would be knowing how much memory is being held in the TIFF library for each open file. The existence of the SetMax*MemAlloc functions mean it must already be tracked internally, it's just a matter of whether I can easily get to it. > On Sep 19, 2024, at 12:59 AM, Milian Wolff <[email protected]> wrote: > > While I agree that forwarding more information might be useful, I would like > to point out that your question might also be answered in a more library- > agnostic fashion via generic memory profiling. -- Larry Gritz [email protected]
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
