> Since we're never freeing any memory, it continually is allocating a block > of size 56 (memory pool) + 1 (character) from the underlying system api.
Note that Parrot_alloc_new_block will allocate a minimum of DEFAULT_SIZE (set in config.h; currently 32768), so this situation is not quite as bad as it first appears. > Each time through the array, it has to alloc a PMC header. When we > allocate the header, we store it into P0, and the old header is > essentially freed. > > The next time through the loop, entries_in_pool is 0, and it triggers > alloc_more_string_Headers, and a dod run. This finds the PMC we just > freed, and uses it. Repeat. Each time through the loop, it triggers a dod > run. As another example, doing a 5000-generation run of life.pasm ends up on my system with numbers like: 5000 generations in 91.883605 seconds. 54.416672 generations/sec A total of 32768 bytes were allocated A total of 130932 DOD runs were made A total of 10930 collection runs were made Copying a total of 0 bytes There are 81 active Buffer structs There are 256 total Buffer structs In other words, each generation is causing an average of 26 DOD runs. This code does not use PMCs, but string headers exhibit the same problem. Clearing S0 to S14 to zero after the initialisation code, which makes 15 additional free string headers available for the rest of the program, reduces the number of DOD runs by about 15000. One option might be a threshold - if, after the DOD run, there is still less than N headers available, allocate more even though we can satisfy the immediate requirement. This would improve performance by reducing the number of DOD runs, but at the cost of additional memory - a classic tradeoff! -- Peter Gibbs EmKel Systems
