Re^3: help with memory leak

Don't worry about uname. What you've shown indicates we're using the same Perl version but completely different OSes: I'm using Mac OS X; you're using MS Windows.

Be aware how the number of iterations grows with respect to $rep: 4 = 4; 5 = 10; 10 = 120; 20 = 1140; 100 = 161700; and so on.

You didn't indicate how the code changes affected the leaks. My tests still show no leaks — I'm unable to reproduce your problem.

I can't see any leak-related isues with %haystack; although, that doesn't mean there aren't any. I do note that you're populating @wants twice with what appears to be the same data:

my @wants = grep { is_approximately_an_integer( @$_ ) } values %haysta
+ck;

# intervening comments here only

@wants = grep { is_approximately_an_integer( @{$haystack{$_}} ) } keys
+ %haystack;
[download]

Obviously, you only want one of those. Also, if %haystack is only used to populate @wants (you don't show any other usage in your code), consider whether the is_approximately_an_integer() filter might be better placed in the innermost loop (possibly doing away with %haystack altogether).

-- Ken

Comment on Re^3: help with memory leak Select or Download Code

Replies are listed 'Best First'.
Re^4: help with memory leak by crunch_this! (Acolyte) on Apr 18, 2013 at 18:31 UTC
Changing the code doesn't change whether or not leaktrace detects any leaks, including putting the subroutine in the innermost loop. How could I do this without %haystack, since if there are actually no memory leaks I think that would probably be much less of a drag on my computer? & simpler is better imho. I'm open to anything that would work. The function no_leaks_ok says there aren't any leaks so I'm with you there but leaktrace -verbose says Read more... (2 kB)	[reply] [d/l]
Re^5: help with memory leak by kcott (Archbishop) on Apr 18, 2013 at 19:37 UTC
Going back to the Test::LeakTrace documentation, specifically the part I quoted in my original response, you'll see: "Thus, to trace true leaks, `no_leaks_ok()` ...". So, if the documentation is to be believed, and `no_leaks_ok()` is showing no leaks with the modified code, then it would follow that you now have no true leaks. Problem solved! In your code, the only use you show for `%haystack` is to conditionally populate `@wants`. So, rather than coding: `my %haystack; ... $haystack{"$x, $y, $z"} = [ poly_roots( ... my @wants = grep { is_approximately_an_integer( @$_ ) } values %haysta +ck;` [download] I'm suggesting you do something like this (which does away with `%haystack` altogether): `my @wants; ... push @wants, grep { is_approximately_an_integer( @$_ ) } [ poly_roots( ...` [download] -- Ken	[reply] [d/l] [select]
Re^4: help with memory leak by crunch_this! (Acolyte) on Apr 18, 2013 at 21:14 UTC
I'm suggesting you do something like this (which does away with %haystack altogether): `my @wants; ... push @wants, grep { is_approximately_an_integer( @$_ ) } [ poly_roots( ...` OK that works much better, more efficient & no problems of any kind with leaktrace or no_leaks_ok, etc. The reason I thought a hash would be a good idea was that I'm also interested in getting back the corresponding $x, $y, $z at the end. That's why the coeffecients look the way they do in the poly_derivative definition. Is there a way to do that without using a hash? If not I'd still gladly trade that for more efficiency because I can always integrate what I get, or I could just work with the coefficients rather than the zeros.	[reply] [d/l]
Re^5: help with memory leak by kcott (Archbishop) on Apr 18, 2013 at 21:58 UTC
Something like this perhaps: `... push @wants, map { { join('-', $x, $y, $z) => $_ } } grep { is_approximately_an_integer( @$_ ) } [ poly_roots( ...` [download] -- Ken	[reply] [d/l]
Re^6: help with memory leak by crunch_this! (Acolyte) on Apr 18, 2013 at 23:17 UTC
awesome! thx for the help, & sorry about the PMs, I didn't know I could customize how many replies would show up.	[reply]