Re: Garbage collection problem??

Replies are listed 'Best First'.
Re^2: Garbage collection problem?? (Win32 CRTL malloc) by tye (Sage) on Dec 27, 2006 at 18:24 UTC
No, I don't think the problem has anything to do with ActiveState nor their version of Perl. Though I don't see any reports using ActivePerl other than on Win32 (yes, they make such), I doubt that the problem would appear there. My guess based on the results is that the blame can likely be placed on the malloc() of Win32's CRTL and that cygwin-built Perls doesn't use that version of malloc(). In any case, testing with my non-ActiveState Perl on Win32 gives: `C:\> perl checkpairs.pl Section A took 0.7500 CPU seconds Section B took 2.5470 CPU seconds Section A took 0.7340 CPU seconds Section B took 13.8280 CPU seconds` [download] Which certainly disproves that it "only occurs in ActivePerl". (: And I've certainly seen Win32's malloc() cause performance problems. I haven't read the code for it recently but I'm quite familiar with some of the memory use patterns that it produces and those clearly show a very naive algorithm. Anyone got a Win32 (non-cygwin) Perl built with profiling? - tye	[reply] [d/l]
Re^3: Garbage collection problem?? (Win32 CRTL malloc) by BrowserUk (Patriarch) on Dec 27, 2006 at 20:27 UTC
Actually, it appears to be more to do with realloc and/or free rather than malloc per se, but also there seem to be some pretty strange things going on with respect to error handling. I get the impression, but haven't got proof yet, that it may be something to do with the way Perl is using the CRT, possibly to do with how it handles errors. Has anyone tried the OP code on a non-threaded 5.8.x Win32 build? There are lots ( literally millions) of repetitions of the call sequence: `... [T1868] GetLastError(2845dc, 18f5ca4, 77c35292, 2803000e, ...) = 3 [T1868] TlsGetValue(0, 2845dc, 18f5ca4, 77c35292, ...) = 281ea0 [T1868] SetLastError(3, 2845dc, 18f5ca4, 77c35292, ...) = 7ffde000 [T1868] GetLastError(2845dc, 18f5ca4, 77c35292, 2803000e, ...) = 3 [T1868] TlsGetValue(0, 2845dc, 18f5ca4, 77c35292, ...) = 281ea0 [T1868] SetLastError(3, 2845dc, 18f5ca4, 77c35292, ...) = 7ffde000 ...` [download] Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]
Re^3: Garbage collection problem?? (Win32 CRTL malloc) by roboticus (Chancellor) on Dec 27, 2006 at 18:52 UTC
Which version of cygwin are you using? My results are using cygwin (v1.5.18) and Perl 5.8.7, and don't show the slowdown on the second run.... --roboticus	[reply]
Re^4: Garbage collection problem?? (Win32 CRTL malloc) by tye (Sage) on Dec 27, 2006 at 19:23 UTC
Where did I say I was using cygwin? That wouldn't make sense given that I said: the blame can likely be placed on the malloc() of Win32's CRTL and that cygwin-built Perls doesn't use that version of malloc() But I did find a cygwin perl and see that "perl -V" for it reports "usemymalloc=y" while non-cygwin Win32 Perl reports "usemymalloc=n", as I suspected. - tye	[reply]
Re^5: Garbage collection problem?? (Win32 CRTL malloc) by roboticus (Chancellor) on Dec 27, 2006 at 19:31 UTC
Re^6: Garbage collection problem?? (Win32 CRTL malloc) by vek (Prior) on Dec 27, 2006 at 20:39 UTC
Re^3: Garbage collection problem?? (Win32 CRTL malloc) by Herkum (Parson) on Dec 27, 2006 at 19:26 UTC
If you look at my tests, they are not using Windows at all nor is it using ActivePerl. Some people have said that it is not an issue on their system but have not posted what type of system they are running (except for OS X). Update: You are correct, I misread your post, sorry about that...	[reply]
Re^4: Garbage collection problem?? ("second") by tye (Sage) on Dec 27, 2006 at 19:31 UTC
No, you misunderstand the problem statement. Your results don't show the problem: `sgkirkup@72sp691lin:~$ ./performance-test.pl Section A took 0.8600 CPU seconds Section B took 2.1800 CPU seconds Section A took 0.8800 CPU seconds Section B took 2.2200 CPU seconds` [download] The problem isn't that "Section B" takes longer than "Section A", but that the second run of "Section B" takes longer than the first run of "Section B" (and not just slightly longer). - tye	[reply] [d/l]