@Gargron there is a related issue in the lilliput tracker: https://github.com/discordapp/lilliput/issues/47

Quote:
> ...it looks like you might be allocating a new Ops each time you transform an image. You will most likely want to create a pool of these at the start of your program and then keep them around forever.

@Gargron have you tried to use sync.Pool qui reuse objects instead reallocating one for each image?

https://godoc.org/sync#example-Pool

@Gargron that object doesn't seem to be request specific, so it should be created in the outer scope.

@gargron I think this has been answered with the sync.Pool bit, but also worth mentioning: IIRC Go handles memory in a way that looks worse than it is, which raised a lot of eyebrows early on. Something along the lines of "Go never fully deallocates memory it's been granted by the OS but marks unused memory as suitable for aggressive paging".
So apparently it can look like it's consuming the entire RAM chip but actually, isn't. But I don't have the OS chops to give more detail/keywords.

@Gargron absolutely no idea, but you can try "env GOGC=20" or something like that

@Gargron this discussion on memory leaks suggest keeping a pool of imageops instead of making a new one on one each request https://github.com/discordapp/lilliput/issues/47

@Gargron Huh, I made the same thing in node.js

@Gargron @grimmy