Thank you for investigating. I've got a different behaviour.
Piggy calls the GC seperate times. Normally the memory in use will reduce with any of the calls but the memory peak caused by the zip operation stays resident. At least on my machine with the reported versions.
I've tested this with large numbers of jpg-files that had an average size above 2 MB. The resulting zip files where a lot greater than 9 MB but below 100 MB.
Cheers
Sascha
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll check, why there's still something like GC.disable in the Piggy code. I guess I took it from some FXRuby tutorial or example. Thanks for the hint.
But nevertheless: Your analysis doesn't match my observations. In Piggy the zip operation is followed by some other memory consuming operations. The memory used by these later operations gets freed when I call GC.start. The memory used by Rubyzip doesn't get freed.
This doesn't mean, it must be a bug in Rubyzip. But for me it still looks like there is something wrong.
Cheers
Sascha
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=554308
Originator: NO
Please provide source code to demonstrate the bug.
Logged In: NO
The sourcecode for Piggy is availiable. Just unzip the gem.
Logged In: YES
user_id=554308
Originator: NO
Rubyzip doesn't create any persistent objects when doing zip operations.
I tested the piggy code in a loop. The memory use never goes above 9M which is normal since the GC is not invoked until 8M are malloc'd in ruby.
Logged In: NO
Thank you for investigating. I've got a different behaviour.
Piggy calls the GC seperate times. Normally the memory in use will reduce with any of the calls but the memory peak caused by the zip operation stays resident. At least on my machine with the reported versions.
I've tested this with large numbers of jpg-files that had an average size above 2 MB. The resulting zip files where a lot greater than 9 MB but below 100 MB.
Cheers
Sascha
Logged In: YES
user_id=554308
Originator: NO
It appears to be a bug in Piggy. Calling GC.start doesn't do anything if GC.disable was called first.
Logged In: NO
I'll check, why there's still something like GC.disable in the Piggy code. I guess I took it from some FXRuby tutorial or example. Thanks for the hint.
But nevertheless: Your analysis doesn't match my observations. In Piggy the zip operation is followed by some other memory consuming operations. The memory used by these later operations gets freed when I call GC.start. The memory used by Rubyzip doesn't get freed.
This doesn't mean, it must be a bug in Rubyzip. But for me it still looks like there is something wrong.
Cheers
Sascha