Should have included _memory_usage() of course.
Before Gz tests:
([ /* 18 elements */ "array_bytes":1905732, "callable_bytes":12300, "callback_bytes":2052, "frame_bytes":8766504, "mapping_bytes":12001375, "multiset_bytes":8672, "num_arrays":12609, "num_callables":347, "num_callbacks":4, "num_frames":3, "num_mappings":39106, "num_multisets":542, "num_objects":-345499, "num_programs":1492, "num_strings":33293, "object_bytes":2143552, "program_bytes":9366376, "string_bytes":2072876 ])
After Gz tests:
([ /* 18 elements */ "array_bytes":1904780, "callable_bytes":12300, "callback_bytes":2052, "frame_bytes":8766504, "mapping_bytes":12012607, "multiset_bytes":8672, "num_arrays":12609, "num_callables":347, "num_callbacks":4, "num_frames":3, "num_mappings":39145, "num_multisets":542, "num_objects":-345691, "num_programs":1492, "num_strings":33319, "object_bytes":2143552, "program_bytes":9366376, "string_bytes":2074170 ])
For some reason, there seems to be a very large number of mappings left over from something. What's frame_bytes? Should only 3 frames (whatever that is) really amount for 8.7M of data?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-27 14:40: Subject: Gz testsuite memory usage
I did some simple memory profiling of the testsuite wrt the Gz module.
Before testing Gz:
[...] 001CC000 64576K read/write/exec [ heap ] [...] total 116856K
After tests with constant strings, before tests with random strings:
[...] 001CC000 64576K read/write/exec [ heap ] [...] total 116856K
After all Gz tests:
[...] 001CC000 95936K read/write/exec [ heap ] [...] total 148216K
The last randomness test uses about 32 megs, so it's natural for the heap to grow to 96M if all the 64M that made up the previous heap is actually used. Question is, why would there be 64M used heap space at the entry to the tests? A freshly started pike has only 2.5M of heap, so the previous tests must have left 61M of now unused data still referenced somehow. (Some of it can be attributed to internal fragmentation of course, but considering the size of the block we shouldn't have _that_ much fragmentation.)
I'm going to try it again with some gc()'s sprinkled through the tests.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)