

Perl 5.14 released - Jak3t
http://news.perlfoundation.org/2011/05/perl-514.html

======
telemachos
A fuller changelog is here:
[http://perl5.git.perl.org/perl.git/blob/HEAD:/pod/perldelta....](http://perl5.git.perl.org/perl.git/blob/HEAD:/pod/perldelta.pod)

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.

~~~
pyre
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.)

~~~
tedreed
That's exactly why.

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

------
adulau
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.

~~~
ojosilva
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!

~~~
perlgeek
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 :-)

~~~
ojosilva
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.

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

~~~
jrockway
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.

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

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

------
otterley
Hurray! At last, real IPv6 support.

------
chuhnk
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.

~~~
ojosilva
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.

~~~
chuhnk
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.

