6 ms·

I'm not sure your results are typical. In microbenchmarks, Perl is 2-125x slower than C++: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&l

• hyperbovine 12y ago
  I'm not sure microbenchmarks are typical.
  • haberman 12y ago
    I think they are a pretty good representation of the performance of doing something directly in the language (as opposed to just calling into lower-level libraries written in a different language).
• cleaver 12y ago
  For a general-purpose problem, Perl won't be particularly fast. For a Perl-type problem (scanning and parsing big files), Perl is very fast. Doing a Perl-type problem in a general-purpose language would be considerably slower. However, Python or others will perform much better in the "can I read my own code six months later" benchmark.
  • csirac2 12y ago
    I don't know why I always have to chip in on "perl is unreadable lol" comments, but over the last 8 years apart from a steady trickle of C coding here and there the bulk of my dayjob has moved around from C/Verilog, then I discovered Ruby, then Perl/R/Python, to full-time Python now. It's true that unsupervised, weak coders using perl turn out worse code than in other languages. But it really doesn't take much to produce good code if you have a tiny bit of supervision/discipline (which stems mostly from 80% of perl tutorials on the web are teaching 1997-era perl anti-patterns). And/or if you happen to be a stronger programmer in something else, hopefully you stumble across perlcritic and modern perl patterns more quickly. Well-written Moose code involves less boilerplate, the declarative nature and composability of classes, types and data members with free type/value validation is a delight to maintain, and results in more robust code with a lot fewer silent failures (or objects happily chugging along silently with invalid state) than typical Python classes. Of course, now that I can't use Moose and the Python community actively seems to discourage the very thought of relying on any superset of core Python OO features like enthoughts' traits package - I really want to revisit static/stronger typed programming languages for large projects. So it feels like I've come full-circle in my programming career...
    • pwr22 12y ago
      Well said :). I like Perl but when I write it I'm aiming above all for readability
    • Cyther606 12y ago
      Check out Nim. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers
      • rdtsc 12y ago
        If I had to guess speed is pretty close to C, right. Nim is pretty awesome and has been around for a while. I wish one of big entities out there Google, Mozilla, Microsoft, Apple would have adopted Nim and ran with it instead of inventing their own langauges.
        • bjz_ 12y ago
          At the time when Go and Rust were conceived Nim would have certainly not been on their radar. Both were announced in 2009, at a time when the Nimrod repository had barely even got off the ground[0]. And Nim doesn't really address one of Apple's chief concerns: smoothly transitioning away from Objective-C. [0]: https://github.com/Araq/Nimrod/graphs/contributors https://github.com/Araq/Nimrod/graphs/contributors
  • haberman 12y ago
    > For a Perl-type problem (scanning and parsing big files), Perl is very fast. I think it's a matter of what you're comparing it to. Compared to using Perl for a general-purpose problem, Perl for scanning/parsing is fast. Compared to scanning/parsing with C, Perl is not fast. $ ruby -e '1.upto(1000000) { |n| puts "This is line number #{n}" }' > file $ time perl -ne 'print if /number 12345/' < file [...] real 0m0.193s user 0m0.189s sys 0m0.004s $ time grep "number 12345" file [...] real 0m0.023s user 0m0.019s sys 0m0.005s I gave Perl every possible advantage here. I didn't actually even write any Perl except a regular expression, which is delegated immediately to C. I didn't even write the loop in Perl, I like the Perl main() function handle that. And still the C program is almost 10x faster. Note: these test runs are from Linux. On OS X the Perl results were almost the same, but "grep" was unexplainably way slower. It seems to hang after it's already dumped all of its output. Basically grep on OS X appears to be badly broken somehow.
    • Igglyboo 12y ago
      I think the takeaway is that perl is "fast enough" for perl type problems. Writing a complicated file parser in C would be a nightmare.
      • visarga 12y ago
        When I have a one-time computation job that takes an hour to write and two hours to run in Perl, but in C takes 10 hours to write and half an hour to run, then Perl is faster than C. And these one-time/rare/short jobs are much more frequent than intense, high throughput C code like the nginix web server or the node javascript interpreter.
        • Igglyboo 12y ago
          I see your point, C is definitely the choice for long running jobs or jobs that will be run more than a handful of times, in my experience however I'm writing a lot of one-off scripts that take 30 seconds tops to run so Perl wins out pretty hard over C.
    • 12y ago