[chaley]

Originally Posted by BradV

Thanks for trying this Chaley. It looks like you were seeing a small leak as well.

Not convinced. In a GC language like python, it is very difficult to see the real usage. There might be free memory in python that windows thinks is used. I noted that sometimes if I left calibre alone for a few minutes, memory usage spontaneously reduced.

You went from 104mb to 132mb of working set.

True. However, that is nowhere near the 40MB per book you were reporting, and it remained quite constant after the initial kick.

I think the issue is related to the number of books in my library. I was able to repro the issue on a second computer (using the same database).

I tried it on a 20-book library, a 2000-book library, and a 4000-book library. The initial memory use varied, but the increases did not.

Calibre 0.8.6
9268 book library on E:
OS on C:, Calibre on C:
Win7 Enterprise x86 (32-bit), 2gb RAM

Numbers are the “Working Set (Memory)” as reported by Task Manager

Repro Steps
Start Calibre (229,260k)
Select book, Edit Metadata (245,132k)
Download Metadata (257,778k)
Select 1st entry, Next
Select current cover (256,320k)
Click OK (285,672k)

Is E: a NAS or a second local drive?

There is clearly something different with your edit metadata. In every one of my tests on my three librarys, the maximum increase was 4 MB, and was often zero. You are seeing 16MB.

Are you using the default 2-tab edit metadata window? I don't think there is any difference, but one never knows. Are your covers particularly large (mine are all 500x500 or smaller)? If so, then memory must be allocated to display them, and this isn't an error.

We have another difference. I never use download metadata. and my tests didn't use it. There could be a leak in there, but that experiment will need to wait for another developer who uses it.

I also didn't change covers. which might also account for it.