Am 20.11.2013 09:14, schrieb Sergei Nosov:

On Tue, 19 Nov 2013 19:08:13 GMT, Sönke Ludwig wrote:

On Tue, 19 Nov 2013 10:56:03 GMT, Sergei Nosov wrote:

I experience the same behavior with 0.7.17 (and 0.7.18) versions of vibe.d.

A 1 Gib of memory consumption for 1M requests. Calling GC.collect() doesn't help. Is this the same bug?

Is that for doing client requests or for handling server requests? There was a memory leak that has been fixed in the HTTP client recently, but the fix is in 0.7.18-beta.2 (if that is the 0.7.18 which you have tested). Just now, I've also fixed a possible fiber leak that may have been the cause for a memory leak in a HTTP server.

Using the bench-http-server and bench-http-request example projects, I get stable memory usage now. However, without "VibeManualMemoryManagement" in package.json (i.e. using pure GC allocations) there is still a moderate growth in memory consumption for the benchmark client (about 70MB after 1M requests). Not sure if this is due to false pointers or because of some actual left over references.

(using Windows for testing)

I've been running bench-http-server and ab -n 1000000 -c 10 for testing. Using current master, there doesn't seam to be any leaks any more. The memory consumption is really low - smth about 3.5Mb for the whole time. So, I guess, that's fixed! Thx!

Good to hear. I've noticed that the performance is worse than it was the
last time I did some benchmarking, but that will also improve again
eventually.

If you don't mind I have another question - I've added a readText call in diet file. It simply embeds another html into the page. I assumed that I would notice a memory usage growth, since it returns a string, but that didn't happen. Do you think it's due to the GC collects previously allocated string on each call, or smth else?

It's very likely that the existing GC memory pool is just large enough
to hold the file in memory without letting the actual process memory
usage go up. The memory will then always be reclaimed for further use by
the GC just before the memory pool would have to be enlarged (the GC
always runs a collection in this case).

The only drawback is that now there will be a GC collection run every
few requests, but that will not matter unless the application has to
handle an extremely high number of requests.