> I was starting with a very simple test to decide how to determine where the > memory overuse was coming from,
I'm actually looking at this now as well, though with zip2.pasm instead of quicksort. What I've found is that because zip constructs the result with incremental packing, and since the 3-argument pack is implemented through string_concat, which allocates a new string every time, it chews through vast quantities of memory. At some point, these buffers (which are now ~45k each) stop getting freed, and Parrot grows from < 10M to about 200M before my laptop dies a horrible death. Sort does things much differently, but I wouldn't be surprised if it's hittng the same things-not-being-reclaimed bug as zip. > ["interesting" sorting results] > Am I missing something somewhere? You've probably got it in EBCDIC mode or something. That or it's a "randomized" quicksort, which is supposed to be faster. /s
