search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.92k stars 551 forks source link

Storable considerably slower at storing coderefs #10200

Closed p5pRT closed 11 years ago

p5pRT commented 14 years ago

Migrated from rt.perl.org#73052 (status was 'resolved')

Searchable as RT73052$

p5pRT commented 14 years ago

From @nwc10

I think that this needs consideration before 5.12

----- Forwarded message from Dave Mitchell \davem@​iabyn\.com -----

Envelope-to​: nick@​ccl4.org Delivery-date​: Sun\, 14 Feb 2010 17​:03​:58 +0000 Mailing-List​: contact perl5-porters-help@​perl.org; run by ezmlm Delivered-To​: mailing list perl5-porters@​perl.org Delivered-To​: perl5-porters@​perl.org Date​: Sun\, 14 Feb 2010 17​:03​:34 +0000 From​: Dave Mitchell \davem@​iabyn\.com To​: David Leadbeater \dgl@​dgl\.cx Cc​: perl5-porters@​perl.org Subject​: Re​: Storable considerably slower at storing coderefs In-Reply-To​: \20100213164346\.GB25617@​babylon\.otherwize\.co\.uk X-Disclaimer​: This disclaimer may not be read without permission User-Agent​: Mutt/1.5.19 (2009-01-05)

On Sat\, Feb 13\, 2010 at 04​:43​:46PM +0000\, David Leadbeater wrote​:

On Sat\, Feb 13\, 2010 at 04​:10​:53PM +0000\, David Leadbeater wrote​: [..]

It doesn't look to be B​::Deparse\, the performance of coderef2text seems similar between both versions to me.

Actually I lied. It seems to be related to strings\, e.g.​:

$ cat ~/deparse.pl #!/usr/bin/perl use Benchmark; use B​::Deparse;

timethese(undef\, { deparse => sub { B​::Deparse->new->coderef2text(sub { "x" x 20 }) } });

$ perl5.10.1 ~/deparse.pl Benchmark​: running deparse for at least 3 CPU seconds... deparse​: 3 wallclock secs ( 3.16 usr + 0.00 sys = 3.16 CPU) @​ 2641.46/s (n=8347) $ perl5.11.4 ~/deparse.pl Benchmark​: running deparse for at least 3 CPU seconds... deparse​: 3 wallclock secs ( 3.08 usr + 0.00 sys = 3.08 CPU) @​ 19.81/s (n=61)

If I remove that string and replace with sub { print $foo; }\, then the performance is much the same.

IIRC\, it was a fix related to deparsing constants correctly that has slowed deparse down a lot. I pulled this fix before releasing 5.10.1\, which is why 5.10.1 doesn't suffer the slowdown.

-- "But Sidley Park is already a picture\, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged." -- Lady Croom\, "Arcadia"

----- End forwarded message -----

p5pRT commented 14 years ago

From @iabyn

On Tue\, Feb 23\, 2010 at 11​:45​:37AM -0800\, Nicholas Clark wrote​:

I think that this needs consideration before 5.12

[snip deparsing constants stuff]

So I'm not sure if

1​: It should be disabled in B​::Deparse by default 2​: B​::Deparse has a way to disable it\, and Storable should disable that by default 3​: other that I've not thought of

Long term\, it might make sense to convert the symbol table walking code to XS\, as I suspect that it will speed it up considerably.

I haven't managed to think of any simple (i.e. suitable for 5.12) way to fix this.

My feeling is that is should be disabled for 5.12\, as it hasn't been in any production releases\, and it's mostly decorative​: i.e. its nice to have something deparsed as "MATH​::PI" rather than "3.141"\, but mostly it doesn't make any functional change to the deparsed code.

Also\, its currently slightly buggy on threaded build vis-a-vis packages​:

  package Foo;   use constant Bar => 10;   my $s = sub { $x + Bar };   package main;   my $t = sub { $x + Foo​::Bar };   use B​::Deparse;   print B​::Deparse->new->coderef2text($s)\,"\n";   print B​::Deparse->new->coderef2text($t)\,"\n";

outputs​:

  {   package Foo;   $x + Bar;   }   {   $x + 10;   }

I also think that there *shouldn't* be a flag in Deparse to optionally enable it\, because when this is fixed properly we want that to be on by default\, and then you get into a mess of either changing the default at some point\, which will surprise people\, or people will always have to explicitly enable it.

If I don't hear any contrary opinions\, I'll disable it tomorrow.

As for long term fixes\, clearly doing the walk via XS will be faster\, although still inefficient. An alternative would be to tack the name of the constant onto every relevant OP_CONST op when its created\, but that might incur a slight space/time penalty for all code\, even that not using Deparse.

Although compared with the cost of calling constant​::import() for every constant that's declared\, the time overhead should be negligible.

(Actually\, thinking about it\, making constant​::import XS would probably be a good idea.)

-- A major Starfleet emergency breaks out near the Enterprise\, but fortunately some other ships in the area are able to deal with it to everyone's satisfaction.   -- Things That Never Happen in "Star Trek" #13

p5pRT commented 14 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 14 years ago

From @rafl

As the author of the original feature\, I also have no objections whatsoever against reverting it.

At the time\, i was simply looking for an easy perltodo to fill a boring afternoon. I'll be happy to try to solve this in a different way once 5.12 is out.

p5pRT commented 14 years ago

From @nwc10

On Mon\, Mar 08\, 2010 at 11​:49​:53AM +0000\, Dave Mitchell wrote​:

On Tue\, Feb 23\, 2010 at 11​:45​:37AM -0800\, Nicholas Clark wrote​:

I think that this needs consideration before 5.12

[snip deparsing constants stuff]

So I'm not sure if

1​: It should be disabled in B​::Deparse by default 2​: B​::Deparse has a way to disable it\, and Storable should disable that by default 3​: other that I've not thought of

Long term\, it might make sense to convert the symbol table walking code to XS\, as I suspect that it will speed it up considerably.

I haven't managed to think of any simple (i.e. suitable for 5.12) way to fix this.

My feeling is that is should be disabled for 5.12\, as it hasn't been in any production releases\, and it's mostly decorative​: i.e. its nice to have something deparsed as "MATH​::PI" rather than "3.141"\, but mostly it doesn't make any functional change to the deparsed code.

I'm fine with that. Rafl commented in agreement at http​://rt.perl.org/rt3/Ticket/Display.html?id=73052#txn-665834

Also\, its currently slightly buggy on threaded build vis-a-vis packages​:

package Foo;
use constant Bar => 10;
my $s = sub \{ $x \+ Bar \};
package main;
my $t = sub \{ $x \+ Foo​::Bar \};
use B​::Deparse;
print B​::Deparse\->new\->coderef2text\($s\)\,"\\n";
print B​::Deparse\->new\->coderef2text\($t\)\,"\\n";

outputs​:

\{
package Foo;
$x \+ Bar;
\}
\{
$x \+ 10;
\}

Interesting. But I don't have time currently to work out why.

I also think that there *shouldn't* be a flag in Deparse to optionally enable it\, because when this is fixed properly we want that to be on by default\, and then you get into a mess of either changing the default at some point\, which will surprise people\, or people will always have to explicitly enable it.

Makes sense.

As for long term fixes\, clearly doing the walk via XS will be faster\, although still inefficient. An alternative would be to tack the name of

I'd like to see how fast an XS walker is\, and in particular as a proportion of the total time taken to deparse\, before deciding what to do longer term.

the constant onto every relevant OP_CONST op when its created\, but that might incur a slight space/time penalty for all code\, even that not using Deparse.

Although compared with the cost of calling constant​::import() for every constant that's declared\, the time overhead should be negligible.

(Actually\, thinking about it\, making constant​::import XS would probably be a good idea.)

I'm hoping that XS is fast enough that this isn't needed. It feels a bit unclean - it's nice that currently constants (and exporting) can be done in pure perl.

Although it is scary\, that running Devel​::NYTProf on the legacy CGI code at work shows constant​::import and Exporter​::import in the top 20 functions.

Although maybe I should edit that down to "it is scary\, the legacy CGI code at work".

But we are well on the way to migrating it to oblivion\, so at some point sooner or later startup costs will be not a problem whose solution has a business case. (Unlike ensuring that persistent process memory use doesn't get out of hand)

Nicholas Clark

p5pRT commented 14 years ago

From @obra

I haven't managed to think of any simple (i.e. suitable for 5.12) way to fix this.

My feeling is that is should be disabled for 5.12\, as it hasn't been in any production releases\, and it's mostly decorative​: i.e. its nice to have something deparsed as "MATH​::PI" rather than "3.141"\, but mostly it doesn't make any functional change to the deparsed code.

I'm ok with that plan.

I also think that there *shouldn't* be a flag in Deparse to optionally enable it\, because when this is fixed properly we want that to be on by default\, and then you get into a mess of either changing the default at some point\, which will surprise people\, or people will always have to explicitly enable it.

If I don't hear any contrary opinions\, I'll disable it tomorrow.

I'm ok with that plan\, too. (Unless someone has come up with a good reason to have the flag in the 6 hours between when I wrote this mail and when I next found internet.)

Thanks! -Jesse

p5pRT commented 14 years ago

From @iabyn

On Mon\, Mar 08\, 2010 at 09​:24​:17PM +0000\, Nicholas Clark wrote​:

(Actually\, thinking about it\, making constant​::import XS would probably be a good idea.)

I'm hoping that XS is fast enough that this isn't needed. It feels a bit unclean - it's nice that currently constants (and exporting) can be done in pure perl.

My throw away comment was largely orthogonal to the original issue. Regardless of how/whether #73052 gets fixed\, constant​::import() seems like an ungodly large chunk of code to be called for every constant that gets defined.

-- The Enterprise successfully ferries an alien VIP from one place to another without serious incident.   -- Things That Never Happen in "Star Trek" #7

p5pRT commented 14 years ago

From @iabyn

On Mon\, Mar 08\, 2010 at 06​:58​:19AM -0800\, Jesse Vincent wrote​:

I haven't managed to think of any simple (i.e. suitable for 5.12) way to fix this.

My feeling is that is should be disabled for 5.12\, as it hasn't been in any production releases\, and it's mostly decorative​: i.e. its nice to have something deparsed as "MATH​::PI" rather than "3.141"\, but mostly it doesn't make any functional change to the deparsed code.

I'm ok with that plan.

I also think that there *shouldn't* be a flag in Deparse to optionally enable it\, because when this is fixed properly we want that to be on by default\, and then you get into a mess of either changing the default at some point\, which will surprise people\, or people will always have to explicitly enable it.

If I don't hear any contrary opinions\, I'll disable it tomorrow.

I'm ok with that plan\, too. (Unless someone has come up with a good reason to have the flag in the 6 hours between when I wrote this mail and when I next found internet.)

Now reverted with 0fa4a26596a4646f9aae1dcd199a2f30933e6f01.

The RT ticket shouldn't be closed yet (we need to fix this properly post 5.12)\, but it can be removed from the 5.12 blockers list.

-- In England there is a special word which means the last sunshine of the summer. That word is "spring".

p5pRT commented 14 years ago

From @obra

I haven't gone digging\, but v5.11.5-91 is the same rev that backed out changes to B​::Deparse. And I don't recall NetBSD failing B​::Deparse tests recently.

-Jesse

----- Forwarded message from Steven Schubiger \stsc@​refcnt\.org -----

Date​: Wed\, 10 Mar 2010 21​:20​:43 -0800 (PST) From​: Steven Schubiger \stsc@​refcnt\.org To​: smokers-reports@​perl.org Cc​: perl5-porters@​perl.org Subject​: Smoke [5.11.5] v5.11.5-91-g0fa4a26 FAIL(XF) netbsd 5.0.2 (i386/1 cpu)

Automated smoke report for 5.11.5 patch 0fa4a26596a4646f9aae1dcd199a2f30933e6f01 v5.11.5-91-g0fa4a26 p5netbsd​: Intel 686-class (i386/1 cpu)   on netbsd - 5.0.2   using cc version 4.1.3 20080704 prerelease (NetBSD nb2 20081120)   smoketime 6 hours 34 minutes (average 49 minutes 17 seconds)

Summary​: FAIL(XF)

O = OK F = Failure(s)\, extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during​: - = unknown or N/A c = Configure\, m = make\, M = make (after miniperl)\, t = make test-prep

v5.11.5-91-g0fa4a26 Configuration (common) none ----------- --------------------------------------------------------- X X X X
X X X X -Duse64bitint O O O O -Duseithreads F O O O -Duseithreads -Duse64bitint | | | +----- PERLIO = perlio -DDEBUGGING | | +------- PERLIO = stdio -DDEBUGGING | +--------- PERLIO = perlio +----------- PERLIO = stdio

Locally applied patches​:   uncommitted-changes   SMOKE0fa4a26596a4646f9aae1dcd199a2f30933e6f01

Failures​: (common-args) none [stdio/perlio] [perlio] -DDEBUGGING [stdio/perlio] -Duse64bitint [stdio/perlio] -DDEBUGGING -Duse64bitint Inconsistent test results (between TEST and harness)​:   ../t/dist/B-Deparse/t/deparse.t.........FAILED at test 61

[stdio] -DDEBUGGING Inconsistent test results (between TEST and harness)​:   ../t/dist/B-Deparse/t/deparse.t.........FAILED at test 61   ../t/op/rand.t..........................FAILED at test 5

[stdio] -Duseithreads -Duse64bitint   ../lib/Benchmark.t..........................................FAILED   126-127   Non-zero exit status​: 2

Compiler messages(gcc)​: perlio.c​: In function 'PerlIOStdio_set_ptrcnt'​: perlio.c​:3437​: warning​: pointer targets in assignment differ in signedness /usr/include/sys/cdefs_elf.h​:67​:20​: error​: missing binary operator before token "(" \​:1​:1​: warning​: "TIME_HIRES_STAT" redefined \​:1​:1​: warning​: this is the location of the previous definition APItest.xs​: In function 'XS_XS__APItest_pmflag'​: APItest.xs​:930​: warning​: 'Perl_pmflag' is deprecated (declared at ../../proto.h​:2622)

-- Report by Test​::Smoke v1.43 build 1271 running on perl 5.10.1 (Reporter v0.035 / Smoker v0.045)

----- End forwarded message -----

p5pRT commented 14 years ago

From @iabyn

On Thu\, Mar 11\, 2010 at 07​:57​:55AM +0100\, Jesse Vincent wrote​:

I haven't gone digging\, but v5.11.5-91 is the same rev that backed out changes to B​::Deparse. And I don't recall NetBSD failing B​::Deparse tests recently.

I presume that's the issue that Rafael fixed with

  commit 719c50dc98237b0afc704520ff22b1b82bf9a101   Author​: Rafael Garcia-Suarez \rgs@​consttype\.org   AuthorDate​: Thu Mar 11 10​:53​:43 2010 +0100   Commit​: Rafael Garcia-Suarez \rgs@​consttype\.org   CommitDate​: Thu Mar 11 10​:53​:43 2010 +0100

  Re-TODO one more Deparse test  
  (was missing from 0fa4a26596a4646f9aae1dcd199a2f30933e6f01)

(although I haven't seen any -93 or later smokes to confirm it yet)

-- That he said that that that that is is is debatable\, is debatable.

p5pRT commented 14 years ago

From @obra

On Thu\, Mar 11\, 2010 at 08​:12​:03PM +0000\, Dave Mitchell wrote​:

On Thu\, Mar 11\, 2010 at 07​:57​:55AM +0100\, Jesse Vincent wrote​:

I haven't gone digging\, but v5.11.5-91 is the same rev that backed out changes to B​::Deparse. And I don't recall NetBSD failing B​::Deparse tests recently.

I presume that's the issue that Rafael fixed with

That does seem a safe bet :)

commit 719c50dc98237b0afc704520ff22b1b82bf9a101
Author&#8203;:     Rafael Garcia\-Suarez \<rgs@&#8203;consttype\.org>
AuthorDate&#8203;: Thu Mar 11 10&#8203;:53&#8203;:43 2010 \+0100
Commit&#8203;:     Rafael Garcia\-Suarez \<rgs@&#8203;consttype\.org>
CommitDate&#8203;: Thu Mar 11 10&#8203;:53&#8203;:43 2010 \+0100

Re\-TODO one more Deparse test

\(was missing from 0fa4a26596a4646f9aae1dcd199a2f30933e6f01\)

(although I haven't seen any -93 or later smokes to confirm it yet)

-- That he said that that that that is is is debatable\, is debatable.

--

p5pRT commented 14 years ago

From @khwilliamson

jesse wrote​:

On Thu\, Mar 11\, 2010 at 08​:12​:03PM +0000\, Dave Mitchell wrote​:

On Thu\, Mar 11\, 2010 at 07​:57​:55AM +0100\, Jesse Vincent wrote​:

I haven't gone digging\, but v5.11.5-91 is the same rev that backed out changes to B​::Deparse. And I don't recall NetBSD failing B​::Deparse tests recently. I presume that's the issue that Rafael fixed with

That does seem a safe bet :)

commit 719c50dc98237b0afc704520ff22b1b82bf9a101
Author&#8203;:     Rafael Garcia\-Suarez \<rgs@&#8203;consttype\.org>
AuthorDate&#8203;: Thu Mar 11 10&#8203;:53&#8203;:43 2010 \+0100
Commit&#8203;:     Rafael Garcia\-Suarez \<rgs@&#8203;consttype\.org>
CommitDate&#8203;: Thu Mar 11 10&#8203;:53&#8203;:43 2010 \+0100

Re\-TODO one more Deparse test

\(was missing from 0fa4a26596a4646f9aae1dcd199a2f30933e6f01\)

(although I haven't seen any -93 or later smokes to confirm it yet)

-- That he said that that that that is is is debatable\, is debatable.

I had failures when I did a pull yesterday; but after today's pull\, they work.

p5pRT commented 13 years ago

From @cpansprout

On Mon Mar 08 03​:50​:48 2010\, davem wrote​:

I also think that there *shouldn't* be a flag in Deparse to optionally enable it\, because when this is fixed properly we want that to be on by default\, and then you get into a mess of either changing the default at some point\, which will surprise people\, or people will always have to explicitly enable it.

Constants should *not* be enabled with B​::Deparse\, as it takes away much of the usefulness of Deparse (to see whether constant folding is working correctly). If you have them on by default\, then I will have to disable them explicitly every time I use Deparse\, which will result in code like $]\<5.0159999?(...)​:().

p5pRT commented 13 years ago

From @demerphq

On 23 February 2010 20​:45\, Nicholas Clark \perlbug\-followup@&#8203;perl\.org wrote​:

# New Ticket Created by  Nicholas Clark # Please include the string​:  [perl #73052] # in the subject line of all future correspondence about this issue. # \<URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=73052 >

I think that this needs consideration before 5.12

----- Forwarded message from Dave Mitchell \davem@&#8203;iabyn\.com -----

Envelope-to​: nick@​ccl4.org Delivery-date​: Sun\, 14 Feb 2010 17​:03​:58 +0000 Mailing-List​: contact perl5-porters-help@​perl.org; run by ezmlm Delivered-To​: mailing list perl5-porters@​perl.org Delivered-To​: perl5-porters@​perl.org Date​: Sun\, 14 Feb 2010 17​:03​:34 +0000 From​: Dave Mitchell \davem@&#8203;iabyn\.com To​: David Leadbeater \dgl@&#8203;dgl\.cx Cc​: perl5-porters@​perl.org Subject​: Re​: Storable considerably slower at storing coderefs In-Reply-To​: \20100213164346\.GB25617@&#8203;babylon\.otherwize\.co\.uk X-Disclaimer​: This disclaimer may not be read without permission User-Agent​: Mutt/1.5.19 (2009-01-05)

On Sat\, Feb 13\, 2010 at 04​:43​:46PM +0000\, David Leadbeater wrote​:

On Sat\, Feb 13\, 2010 at 04​:10​:53PM +0000\, David Leadbeater wrote​: [..]

It doesn't look to be B​::Deparse\, the performance of coderef2text seems similar between both versions to me.

Actually I lied. It seems to be related to strings\, e.g.​:

$ cat ~/deparse.pl #!/usr/bin/perl use Benchmark; use B​::Deparse;

timethese(undef\, {   deparse => sub { B​::Deparse->new->coderef2text(sub { "x" x 20 }) } });

$ perl5.10.1 ~/deparse.pl Benchmark​: running deparse for at least 3 CPU seconds...    deparse​:  3 wallclock secs ( 3.16 usr +  0.00 sys =  3.16 CPU) @​ 2641.46/s (n=8347) $ perl5.11.4 ~/deparse.pl Benchmark​: running deparse for at least 3 CPU seconds...    deparse​:  3 wallclock secs ( 3.08 usr +  0.00 sys =  3.08 CPU) @​ 19.81/s (n=61)

If I remove that string and replace with sub { print $foo; }\, then the performance is much the same.

IIRC\, it was a fix related to deparsing constants correctly that has slowed deparse down a lot. I pulled this fix before releasing 5.10.1\, which is why 5.10.1 doesn't suffer the slowdown.

Just wanted to say that when evaling/compiling perl code there is a non-linear relationship between the time it takes and the number and length of the strings it contains.

Not sure how relevant it is\, but i have done extensive benchmarks on this\, and there is no question that if you can load a string value into a var and then create a closure on the var instead of embedding the string literal in the text of the code and evaling that you will see performance improvements\, the longer the strings the more significant it is.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT commented 11 years ago

From @jkeenan

On Mon Dec 13 10​:20​:35 2010\, demerphq wrote​:

On 23 February 2010 20​:45\, Nicholas Clark \perlbug\-followup@&#8203;perl\.org wrote​:

# New Ticket Created by �Nicholas Clark # Please include the string​: �[perl #73052] # in the subject line of all future correspondence about this issue. # \<URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=73052 >

I think that this needs consideration before 5.12

----- Forwarded message from Dave Mitchell \davem@&#8203;iabyn\.com -----

Envelope-to​: nick@​ccl4.org Delivery-date​: Sun\, 14 Feb 2010 17​:03​:58 +0000 Mailing-List​: contact perl5-porters-help@​perl.org; run by ezmlm Delivered-To​: mailing list perl5-porters@​perl.org Delivered-To​: perl5-porters@​perl.org Date​: Sun\, 14 Feb 2010 17​:03​:34 +0000 From​: Dave Mitchell \davem@&#8203;iabyn\.com To​: David Leadbeater \dgl@&#8203;dgl\.cx Cc​: perl5-porters@​perl.org Subject​: Re​: Storable considerably slower at storing coderefs In-Reply-To​: \20100213164346\.GB25617@&#8203;babylon\.otherwize\.co\.uk X-Disclaimer​: This disclaimer may not be read without permission User-Agent​: Mutt/1.5.19 (2009-01-05)

On Sat\, Feb 13\, 2010 at 04​:43​:46PM +0000\, David Leadbeater wrote​:

On Sat\, Feb 13\, 2010 at 04​:10​:53PM +0000\, David Leadbeater wrote​: [..]

It doesn't look to be B​::Deparse\, the performance of coderef2text seems similar between both versions to me.

Actually I lied. It seems to be related to strings\, e.g.​:

$ cat ~/deparse.pl #!/usr/bin/perl use Benchmark; use B​::Deparse;

timethese(undef\, { � deparse => sub { B​::Deparse->new->coderef2text(sub { "x" x 20 }) } });

$ perl5.10.1 ~/deparse.pl Benchmark​: running deparse for at least 3 CPU seconds... � �deparse​: �3 wallclock secs ( 3.16 usr + �0.00 sys = �3.16 CPU) @​ 2641.46/s (n=8347) $ perl5.11.4 ~/deparse.pl Benchmark​: running deparse for at least 3 CPU seconds... � �deparse​: �3 wallclock secs ( 3.08 usr + �0.00 sys = �3.08 CPU) @​ 19.81/s (n=61)

If I remove that string and replace with sub { print $foo; }\, then the performance is much the same.

IIRC\, it was a fix related to deparsing constants correctly that has slowed deparse down a lot. I pulled this fix before releasing 5.10.1\, which is why 5.10.1 doesn't suffer the slowdown.

Just wanted to say that when evaling/compiling perl code there is a non-linear relationship between the time it takes and the number and length of the strings it contains.

Not sure how relevant it is\, but i have done extensive benchmarks on this\, and there is no question that if you can load a string value into a var and then create a closure on the var instead of embedding the string literal in the text of the code and evaling that you will see performance improvements\, the longer the strings the more significant it is.

Yves

The original subject of this RT was "Storable considerably slower at storing coderefs".

Have we addressed that problem? (There was so much going on in the thread that I can't see the forest for the trees.)

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

From @iabyn

On Fri\, Feb 15\, 2013 at 07​:42​:52PM -0800\, James E Keenan via RT wrote​:

The original subject of this RT was "Storable considerably slower at storing coderefs".

Have we addressed that problem? (There was so much going on in the thread that I can't see the forest for the trees.)

For 5.12.0\, we pulled the code that makes Deparse constants as names rather than values; this means that deparsing (including the deparsing done by Storable) from then on is fast again\, but less elegant.

-- You live and learn (although usually you just live).

p5pRT commented 11 years ago

From @jkeenan

On Sat Feb 23 08​:15​:37 2013\, davem wrote​:

On Fri\, Feb 15\, 2013 at 07​:42​:52PM -0800\, James E Keenan via RT wrote​:

The original subject of this RT was "Storable considerably slower at storing coderefs".

Have we addressed that problem? (There was so much going on in the thread that I can't see the forest for the trees.)

For 5.12.0\, we pulled the code that makes Deparse constants as names rather than values; this means that deparsing (including the deparsing done by Storable) from then on is fast again\, but less elegant.

Thanks for looking into this. Marking ticket resolved.

p5pRT commented 11 years ago

@jkeenan - Status changed from 'open' to 'resolved'