While working on Windows, there is no (really) thing like valgrind, but I'like to ask for suggestions about how to try to figure out why, as far as I could see now, libvips becomes slow.

What is the pattern

We have a stand-alone binary, accessed by gRPC requests and performing libvips C++ operations, e.g. like: crop, resize, composite, gaussblur, bandjoin, gravity, flatten, insert, new_from_memory_copy). After some days, this binary is consuming more and more memory and vips operations become (much) slower. Restart the binary will 'fix' it.

Each gRPC request is handled in one or more separate threads, which could be up to 10 or even more requests, containing a set of vips operations, applied on the input image (that's read from network) and returned as gRPC response (the resulting image is sent as binary data).

Things done

We have used DeLeaker (a Windows-based valgrind counterpart), but did not find leaks (in our code, until now. I've to do more research). I would like to investigate whether libvips leaks memory. Do some of you have some suggestions where to start libvips memory allocations?

Background information

The used libvips version is v8.17.1, but the leakage appears for a longer time. Unfortunatelly, we don't know how long, but at least with two predecessor versions of libvips (8.16.0, 8.15.1). Note that I would just like to investigate a cause why our binary becomes slower. It's not said that libvips is the victim. Other possibilities are of course possible (our own code, gRPC or whatever). We solely rely on memory management of libvips. Libvips concurrenct is set to 4, as that appeared to be a 'good balance' between vips its own thread management and our own.

I understand that this question is vague, sorry, but maybe someone is able to provide advise or a pointer?