suboptimal memory usage of repetition operator #13793
Comments
From efimov@reg.rusuboptimal memory usage of repetition operator ===
|
From @druud62On 2014-05-02 01:23, �ик�о� ��имов wrote:
This "similar thing" uses 200 MB in 5.18, but 100 MB in 5.19: perl -wE' In 5.18 it is better coded like: my -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @AbigailOn Thu, May 01, 2014 at 04:23:33PM -0700, �ик�о� ��имов wrote:
That's because the latter contains "x" x (200*1024*1024) twice. The former just has "x" on the RHS, and that gets reused 200*1024*1024 You can reduce the memory usage of the latter by forcing Perl to release my $s1; Abigail |
From efimov@reg.ru2014-05-02 12:38 GMT+04:00 Abigail <abigail@abigail.be>:
at compile time? but same happening when it's runtime (no constants): my $s1; |
From @AbigailOn Fri, May 02, 2014 at 12:45:05PM +0400, Victor Efimov wrote:
Same thing happens, except it now does it at run time. It calculates Abigail |
From efimov@reg.ruindeed. That is _not_ issue when RHS side copied to LHS side and ===
|
From @AbigailOn Fri, May 02, 2014 at 01:09:18PM +0400, Victor Efimov wrote:
It keeps the internal structures around, so it later doesn't have to
Nothing is reused here, you end up with two pairs of two copies: This, however, will take about 600Mb: my $size = 200*1024*1024; Here we have three copies: $char x $size, $s [0] and $s [1]. Abigail |
From efimov@reg.ru2014-05-02 13:23 GMT+04:00 Abigail <abigail@abigail.be>:
But isn't that a memory leak? $s1 goes out of scope and should be |
From @LeontOn Fri, May 2, 2014 at 10:45 AM, Victor Efimov <efimov@reg.ru> wrote:
You are correct that that is a bug. It seems PADTMP's were not treated as Leon |
From @iabynOn Fri, May 02, 2014 at 10:38:16AM +0200, Abigail wrote:
I rather wonder whether we should not in fact be constant-folding the if ($unlikely_condition) { will consume 200Mb even if that branch is never taken. -- |
From @AbigailOn Fri, May 02, 2014 at 03:22:17PM +0100, Dave Mitchell wrote:
Yeah, that's what I meant by "calculated at compile time". I'm very aware of the effects of constant-folding, once bringing down Abigail |
From @lizmatOn 02 May 2014, at 16:27, Abigail <abigail@abigail.be> wrote:
Yeah. Talking about side-effects :-) Liz |
From @tseeOn 05/02/2014 04:22 PM, Dave Mitchell wrote:
I think this is a corner case. Few real programs have string constants This is always a trade-off. Advocatus diaboli: Should we stop allocation Constant folding is not rocket science. People generally know it's going Maybe the proper solution (in an ideal world, I mean) would be constant --Steffen |
From @avarOn Sat, May 3, 2014 at 11:14 AM, Steffen Mueller <smueller@cpan.org> wrote:
Are we remembering different issues? The one I remember came down to: @cache {1 .. 999_999} = (); I.e. just perl sizing the variable at compile-time even though it |
From @AbigailOn Sat, May 03, 2014 at 12:44:19PM +0200, �var Arnfjörð Bjarmason wrote:
That was the one. Abigail |
From @lizmatOn 03 May 2014, at 21:30, Abigail <abigail@abigail.be> wrote:
Yup, the one. Although the hash was *not* sized at compile time: that happened at runtime using the array created by 1..999999 at compile time. :-) So the idea behind this was doing an optimisation at runtime, with unfortunate severe side-effects at compile time. Liz |
From @lizmatOn 03 May 2014, at 21:53, Elizabeth Mattijsen <liz@dijkmat.nl> wrote:
Actually, going down memory lane, the very quick fix was: eval �@cache {1 .. 999_999} = ()�; Liz |
From @perhunterOn 05/03/2014 04:14 PM, Elizabeth Mattijsen wrote:
why not a quick fix of: $max = 999_999 ; that shouldn't be able to trigger any compile time 'optimizations' of uri -- |
From @tseeOn 05/03/2014 12:44 PM, �var Arnfjörð Bjarmason wrote:
Then I misremembered. But again, this is just a case of "don't do that" --Steffen |
From @AbigailOn Sun, May 04, 2014 at 09:28:48AM +0200, Steffen Mueller wrote:
How many Perl programmers outside of p5p have any idea what perl is It's also rarely documented. Perl, the language, is documented well, Now, I'm not arguing things should change. But compile time actions Abigail |
From @bulk88On Sat May 03 02:14:59 2014, smueller@cpan.org wrote:
I agree with that. If someone will write something like that, it has to have some legitimate purpose. If you write something like that, prepare for your process to have the available free memory to do that. If you don't have the free memory to do that, your accepting the risk of a random process termination and P5P can't help you with that.
I have a different idea but my recommendation on this ticket is to do nothing, if the constant folding results in an SV with more than a 10 MB value, reinstate the original optree. -- |
Migrated from rt.perl.org#121780 (status was 'open')
Searchable as RT121780$
The text was updated successfully, but these errors were encountered: