DAVID GAMEY wrote: > Steve, > > --- Steve Wampler <[EMAIL PROTECTED]> wrote: > > >>Hi David, >> >>DAVID GAMEY wrote: >> >>>... >>>Steve, >>> >>>Just a hunch as this sounds strangely familiar. >> >>Can >> >>>you determine how many strings you're creating and >>>concatenating? >>> >>>I ran into a problem some years back where I was >>>returning map(c,s1,s2) where c was a 1 character >>>string. For each character I would do this 9 >> >>times >> >>>creating 9 new strings. As I was concatenating >> >>the >> >>>result with the previous function a character at a >>>time, it got pathelogical. Even for a few hundred >>>characters of message I overflowed the Icon GC >>>counter. >> >>Hmmm, *that* is interesting. I do create a *lot* of >>temporary strings. But the GC shouldn't see most >>of them as the GC *should* only be following >>referenced links and I'm not getting any errors or >>crash, so an internal overflow seems unlikely. >>However, I haven't come up with any other >>explanation, >>so... >> > > > I don't think it works that way. > > If I do: > > s2 := "" > while s2 ||:= f(read()) > > where f creates a new string, say map to force lower > case, then read() creates a string, f creates a new > string right after it (no space saving optimization). > And concatention does the real damage, since now the > entire string is recopied to the end of the area. > Think about this on a file of 1M records!
I understand that (I think) but, unless things have drastically changed, the old string (previously referenced by s2) is not referenced anymore and so shouldn't be seen as the GC walks the string qualifiers. So during the reclamation phase the storage for the old string should be reclaimed. You will end up calling the GC more often since there's not space optimization available, but the actual storage itself shouldn't grow out of hand. If this *isn't* how it works anymore, then I think I'll claim that Icon's GC is now broken... In any event, I'm creating less than n! strings (my head hurts whenever I try to really work it out, so that's a guess) where n is the length of the input string. Far fewer than that are ever 'referencible' at any one time, of course, somewhere well less than 2^n. At the point I suddenly see the leftover storage after GC, n = 22. The maximum length of any string is n characters, so the total referenced string space should never be greater than n*(2^n) bytes (ignoring the number of qualifiers for the moment). So I max out at less than 92MB of string storage in use, and by the end of the program that should be back to a *very* small value (as seen in the program when n=21). -Steve -- Steve Wampler -- [EMAIL PROTECTED] The gods that smiled on your birth are now laughing out loud. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
