On Fri, 2002-05-24 at 15:10, Sean O'Rourke wrote: > > 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
Actually I was getting the wrong results because I was using ge & le to test the bounds when I should have used gt & lt. The attached quicksort fixes it. Its still _huge_ when the memory runs. Looking at the profile data, it looks like Parrot_pushs is the big time user... % cumulative self self total time seconds seconds calls ns/call ns/call name 66.67 0.02 0.02 singlebyte_decode 33.33 0.03 0.01 646 15479.88 15479.88 Parrot_pushs Of course, if I understood the calling convention, I might get away with less pushs's :) Brian
