New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unacceptable memory consumption #9136
Comments
From @salvaCreated by @salvaThe script below has two versions of the same algorithm, one using "for" and the other "map". The "map" version uses an unacceptable amount of memory. -------------------------- #!/usr/bin/perl $| = 1; my $max = 50000; if (1) { } else { } print "sleeping...\n"; --------------------------- Perl Info
|
From @druud62Salvador Fandiño schreef:
Why is the memory consumption of the map-map version more "unacceptable" There is a scale difference between the two of 50000, so shouldn't the 9 The map-for version can also be written like this: push @keys, join('', map $l[rand @l], 0..71) for 0..$max; I brought it back to 4 MB (RSS), but I am not sure it is equivalent: sub lazymap (&@) { # this version uses ~ 4 MB (RSS) -- "Gewoon is een tijger." |
The RT System itself - Status changed from 'new' to 'open' |
From @schwernSalvador Fandiño (via RT) wrote:
My first thought was that for (1..$x) is optimized to iterate rather than There are other inefficiencies in the map approach, like that it has to build If you half 71 down to 35 the memory usage halves. That should not be. It It's also telling that replacing the inner map with a static string reduces Here is the most damning evidence that the result of the inner map is leaking. @keys = map { That takes 18 megs, as expected. -- |
From @lizmatAt 5:50 AM -0800 12/1/07, Salvador Fandi�±o (via RT) wrote:
What I find most disturbing about this, is that ================================================================= sub foo { join '', map { $l[rand @l] } 0..71 } # this version uses ~ 300MB
|
From @nwc10On Sat, Dec 01, 2007 at 03:52:27PM -0800, Michael G Schwern wrote:
$ perl -MO=Concise -e '@keys = map { join "", map $l[rand @l], 0..71 } 0..$max;' I think that the only place where the temporaries get freed is in the
$ cat schwern48004.pl I see 3 nextstate ops there, which would mean that temporaries are getting So the inner map isn't leaking in absolute terms in the original code, but it I'm not sure how to fix this. I'm also not sure of the best way to measure @keys = map { 1; join "", map $l[rand @l], 0..71 } 0..$max; Adding the seemingly useless 1 constant adds 2 nextstate ops. Maybe pp_mapwhile should FREETMPS? Nicholas Clark |
From @rgsOn 03/12/2007, Nicholas Clark <nick@ccl4.org> wrote:
Maybe at least for the block form of map ? |
From @nwc10On Mon, Dec 03, 2007 at 11:07:51PM +0100, Rafael Garcia-Suarez wrote:
I can't think of a way to break it for the expression form of map, but yes,
It seems to suffer from the same problem. Nicholas Clark |
From @iabynOn Tue, Dec 04, 2007 at 11:16:35AM +0000, Nicholas Clark wrote:
Now fixed with this commit: commit b2a2a90 stop map,grep leaking temps [perl #48004] M pp_ctl.c -- |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#48004 (status was 'resolved')
Searchable as RT48004$
The text was updated successfully, but these errors were encountered: