What do you mean by efficient and cheap? It doesn't fare well in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at least.

There’s something fishy about that report. It says it is presenting the fastest programs, but when I click through to “all perl programs”, there are faster (often by 1-2 orders of magnitude) programs / runs:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

For instance, the page you linked has “pidigits” at the top, and says node is faster, 2.58s vs 3.61.

2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.

The perl page lists a 1.24 second run for “pidigits 2”.

The reported numbers in the language comparisons don’t seem to be averages.

All the pidigits programs list the same output, so presumably, they’re running with the same ‘N’.

Between the variance and inexplicable stats being applied to the results, I’m not sure what to conclude from these numbers.

> There’s something fishy about that report.

No, there really isn't.

> 2.58s is the slowest run of the fastest pidigits on the node page, but one of its runs took 1.04 seconds.

Notice column N — 2,000 6,000 10,000.

That's a command line argument passed to each program, controlling how many digits of pi are generated — the workload.

So, 2.58s for 10,000 digits and 1.04s for 6,000.

(And as it says, there can be a cold caches effect on the first measurements.)

Nodejs is very fast, because it uses an an engine that has had multiple millions of dollars thrown at it to make it fast. Most interpreted languages don't fare well against it.

Perl fares somewhat favorably against Python, Ruby and PHP though. Those are what I would consider equivalent languages to compare against to get a general idea of its speed.

>multiple millions of dollars

I can pretty much assure you the accumulated dollars invested over the years in making JS fast is likely to be closer to multiple billions combined.

You don't hear about it, but Perl has had many millions thrown at it too.

JS is probably closer to billions.

Not just orders of magnitude more money, but more importantly the large number of incredibly talented people working full time on JavaScript, in many different companies and research institutions, collaborating together. JavaScript benefits from an overwhelming network effect and critical mass of tools and developers, that Perl just can't touch, and never will.

Unfortunately it does not change bad parts.

Depends on what you mean by "fare well". Even in those benchmarks, Perl seems to have a lower memory footprint than Node.js in most of the results.

It's also worth noting that three of the examples (pidigits, reverse-complement, fasta) don't seem to do any multiprocessing in Perl whereas they do in Node.js. At least for reverse-complement and fasta, it should be possible to rewrite those to use multithreading (like the Node.js versions do).

> should be possible to rewrite those

Until someone does…

What do you mean by cheap? Also, perl is incredibly inefficient: it's even slower than Python.

Also, how is Perl any less stable than other languages? Are you saying the language doesn't change much or that it doesn't crash?

On my 4-core i7 Macbook Pro:

    time ./startup_time.pl  0.016s
    time ./startup_time.py  0.295s

Parsing a 20Mb log file with a regex:

    time ./parse_log.pl  0.683s
    time ./parse_log.py  1.534s

For which metric are you claiming Perl is slower than Python?

Lets see the code? Regex has always been a Perl selling point, and you're just benchmarking the Python Regex library (written in C) against Perl's regex library. That's not a fantastic basis for a comparison.

Perl 5:

    #!/usr/bin/env perl
    use 5.026;

    open my $fh, '<', 'logs1.txt';
    while (<$fh>) {
      chomp;
      say if /\b\w{15}\b/;
    }
    close $fh;

Python 3.8

    #!/usr/bin/env python

    import re

    with open('logs1.txt', 'r') as fh:
        for line in fh:
            if re.search(r'\b\w{15}\b', line): print(line,   end='')

Why isn't it a fair comparison? The startup time is generic and string parsing is a major feature of, say, web development. I didn't say Perl5 numerics match Python's but even there Python relies on external libs.

It doesn't account for anywhere near the whole difference, but in a tight loop like that Python's going to be spending a good chunk of its time re-compiling the regex from the raw string literal every iteration. Hoist the regex definition out of the loop like so and it'll probably run about 30% faster:

  #!/usr/bin/env python3

  import re

  with open('logs1.txt', 'r') as fh:
      regex = re.compile(r'\b\w{15}\b')
      for line in fh:
          if regex.search(line): print(line, end='')

Perl almost certainly does this by default for regex literals, and that's a fair advantage for the "kitchen sink" style of language design versus orthogonal features (regex library, raw strings) that Python uses.

With pre-compiled regex the Python version comes down to 1.483s on my machine which is still considerably slower than Perl. I wrote versions of these using substring `index` instead of a regex and Perl was still the clear winner:

    time ./index.pl  0.258s
    time ./index.py  0.609s

If you factor-in that Python startup time is 0.279s slower than Perl the processing differential comes down to 0.072s.

I'd be curious on your take of my code below, I have python and perl as dead even if you don't print and ignore pythons startup time.

Well, the two ifs you hedge to qualify Python's parity are pretty damning in themselves, no? Let's stop beating about the bush - if you want to perform a common text-processing job like parsing a log file Perl is hands down faster than Python.

Python caches patterns, you almost never need to re.compile unless you’re a library or have a specific use case involving lots of unique patterns.

The issue here is that pythons regex engine has overhead, and with lots of sequential calls with small strings like that the overhead adds up.

If you batch lines together in chunks you’ll see a huge improvement in speed, but the point is that it’s not “Python vs Perl” it’s “pythons regex engine vs Perl’s regex engine”. Which is about a contrived Perl-biased benchmark if ever there was one.

Running a different test the slowest part of the python script is the startup time, otherwise they're identical:

    [admin@localhost ~]$ time ./test.py
    real 0m0.295s
    user 0m0.158s
    sys 0m0.138s

    [admin@localhost ~]$ time ./test.pl
    real 0m0.164s
    user 0m0.158s
    sys 0m0.006s

    #!/usr/bin/env perl
    use 5.16.3;

    open my $fh, '<', 'logs1.txt';
    while (<$fh>) {
    chomp;
    if (/\b\w{15}\b/) {}
    }
    close $fh;

    #!/usr/bin/env python

    import re
    regex = re.compile(r'\b\w{15}\b')

    with open('logs1.txt', 'r') as fh:
     for line in fh:
      if regex.search(line):
       continue

The python code should run much faster if you don't print..

Edit: perl is still faster, to be clear

That's like saying they're both as fast if you amputate one of Perl's legs.

I took some similar benchmarks recently: https://code.ivysaur.me/interpreter-binary-perf

Perl5 won the dec2bin benchmark.

The other thing I learned was that PHP's binary/decimal functions are two orders of magnitude slower, despite its core interpreter performance being best-in-class.

On the other hand PHP has a PCRE jit option which manages to beat even Perl's regex implementation.

Yes but you can use that jit also with perl5. https://metacpan.org/pod/re::engine::PCRE2

It has even less backcompat problems than the native regex.

> it's even slower than Python.

It's faster at some things and slower at others. It's fairly similar in speed profile to Python in my eyes.

> Are you saying the language doesn't change much or that it doesn't crash?

Both is probably what was meant. They are literally changing the major version so they can change some backwards compatibility, as Perl has made strong backwards compatibility a goal and selling point for decades. You can take a script written in 2000, and it will likely run without problem if you run it on a Perl 5.30, released last year.

- Efficient: from prototype to deployment, it's a matter of days. The choice of styles let people use paradigms they are familiar with, meaning they do things quickly.

- Cheap: it does not cost much to hire someone to write perl. If they don't know how yet, the choice in style let them be efficient quickly. The code to be deployed is very lightweight, both in CPU and RAM usage.

- Stable: no API break. No new module that reinvent the wheel and breaks your codebase. Unit testing is about everywhere in cpan. Code written 20 years ago still run fine.

The reason that code written 20 years ago still runs fine is that they rolled back 20 years of changes!

This is a pointless attack. The modules available on CPAN usually have a strong emphasis on backwards compatibility.

> Also, perl is incredibly inefficient: it's even slower than Python.

That's debatable for single-threaded workloads (they're typically pretty comparable in my observation), and highly unlikely for multi-threaded workloads (Python has a global interpreter lock whereas Perl does not AFAICT; you can work around that in Python, but it typically involves spawning entirely separate processes, thus introducing IPC overhead that wouldn't be present in a Perl equivalent).

Looking at some comparative benchmarks (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...), Perl seems to be faster in a slight majority of cases, and in nearly all cases has a lower memory overhead. Not that benchmarks really matter anyway, given that they're usually a poor indicator of real-world performance, but still.