Perl 5.14 released | Hacker News Reader

Perl 5.14 released

news.perlfoundation.org

105 pointsJak3t26 comments

A fuller changelog is here: http://perl5.git.perl.org/perl.git/blob/HEAD:/pod/perldelta....

There's a lot going on here, but a couple jump out at me:

* Non-destructive substitutions (with a new 'r' option)

* An experimental feature that allows you to perform operations like push, pop, splice, keys and company directly on (unblessed) array and hash references. (There's a pretty strong warning that this feature is subject to change.)

There are also enhancements for Unicode, regular expressions, exception handling and more.

Hmmm... perldoc.perl.org doesn't have 5.14 as an option yet. I assume that the 'r' option is meant to prevent things like this:

  my @list = (... stuff ...);
  my @other_list = map { s/SOMETHING//; $_ } @list;

(The result of this is that @other_list and @list are equal because the substitution destructively affects the original list.)

That's exactly why.

(Incidentally, perlcritic will warn you if you have a map that modifies $_.)

Along with that, it's also for doing things like

  my $old = "foo"; my $new = $old =~ s/foo/bar/r;

$old still contains "foo" and $new contains "bar", but inside a map should be great as well.

There's a more readable changelog here:

http://search.cpan.org/~jesse/perl-5.14.0/pod/perldelta.pod

There are many important updates regarding memory use. That's an interesting improvement especially when you have long lasting Perl script in distributed environment. Especially that we can gain some memory on some data structure, it's always an interesting gain.

We have been testing perl 5.14 RC2 version in one of our dev box during last week, and the performance improvements are just monstrous! Got a 20-30% faster app straight out of the box, and some hefty memory savings. It's really noticeable on smaller scripts. Can't wait to put 5.14 in production!

20% to 30% has typically been the difference between threaded and non-threaded perl interpreters.

Have you checked if both your old and the new perl have the same threading settings?

I expected some performance improvements from the upgrade, but I found 20% to be pretty surprising -- still I won't complain :-)

Nope, no useithreads in either of them. We haven't build a threaded perl in ages.

The noted speed improvement is for a hefty Catalyst + DBIC + Moose app. Also seen similar performance improvements in a smaller Dancer app we have. Maybe it's related to the BUFSIZ changes.

What older version were you comparing to?

What is happening with perl 6? And will perl developers actively work on perl 5 after .14?

Perl 6 is a completely different programming language and is generally unrelated to Perl 5 except in name, history, and a common group of comitters and users.

Perl 5 releases a new major version every year, and a new development version every month. So 5.16 will be around next spring, and 5.18 will be around the spring after that.

With thousands of users around the world, Perl 5 is not going away any time soon.

I love Perl, long live Perl 5, thanks to decimal system, we can have 5.99999... ;)

Though with an infinite number of nines, it becomes Perl 6.

As jrockway said, Perl 5 and Perl 6 development is mostly decoupled. I write some code for Perl 6 compilers, and now and then contribute a (most often doc) patch to Perl 5.

Both move along nicely, and Perl 5 gets many inspirations from Perl 6 - not the least of it is a time-based release schedule, which is why you see many more releases of Perl 5 in the last two years.

Hurray! At last, real IPv6 support.

I would love to see benchmarks against ruby 1.9.2. Perl always had comparable speed to ruby 1.8.6 with lower memory consumption and cpu usage. Now hopefully it'll be equivalent to ruby 1.9.2.

Not following you here, how can speed of one language be the same as another's, but "with lower cpu usage"?

Sorry I threw that into the same sentence when it made no sense to do so.

CPU does not necessarily have to be the bottleneck.

If you check (historically) the benchmarks on http://shootout.alioth.debian.org/ then:

* perl5 was always a 2-4 times faster than than ruby 1.8

* perl5 & ruby 1.9 are comparable usually swapping places on different "Which programming languages are fastest?" benchmarks

* When taking in above speed benchmarks, memory used & code-used then perl5 just nudges in front of ruby 1.9. See "Which programming language is best?"

How did you check (historically) ?

Here are some quick, unsophisticated benchmarks of a "Hello World" test web server. I ran it in our dev server (Centos 5.3 i386). Ran with ab -t 30 a few times and chose the fastest of the batch.

Perl 5.14, Dancer 1.3040, HTTP::Server::PSGI:

   Requests per second:    856.48 [#/sec] (mean)
   Memory after tests: 11296 (VSZ) 7632 (RSS)

Ruby 1.9.2, Sinatra 1.2.6, WEBRick 1.3.1:

   Requests per second:    402.72 [#/sec] (mean)
   Memory after tests: 20612 (VSZ) 10628 (RSS)

I know. This is not, by any means, serious language benchmarks (ie. Sinatra, WEBRick, Dancer are interfering), but they give me a rough idea of how things can perform side-by-side for a given setup.

I'm also a fan of running quick string management tests to roughly benchmark interpreters at a given servers, since most of our codebase do a lot of string manip. Here's a 1MB mem alloc + cat test:

Ruby 1.9.2:

  $ time ruby -e 'x=""; (1..999999).each { x << "a" }'
  real	0m0.313s
  user	0m0.277s
  sys	0m0.026s

Perl 5.14:

   $ time perl -E '$x.="a" for 1..999999'
   real	0m0.167s
   user	0m0.139s
   sys	0m0.020s

As I said, this is completely unscientific. There are much better ways of benchmarking languages out there.

I'm not sure using time is an accurate measurement of the speed of looping here since there is the cost of starting up the interpreter, but fun nonetheless to see.

I don't think the problem is that "this is completely unscientific."

It just seems really silly ;-)

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

Reply on news.ycombinator.com