Perl is too slow - A statement

[mercurish]

We hear this all too common:
"I have one huge problem with Perl; it is too slow."

But is Perl realy slow, could perl be slow at all?

The problem is that most programmers associate an implementation of a
programming
language with the language it self. The current interpreter is too
slow and hence programmers
think that 'Perl' is too slow.

Perl5 doesn't perform anything to make Perl machine like-able, Perl5
is infact hated by machines
where the Perl5 program is being executed.

Though however, with Perl6 the maintainers of the programming language
are hoping to reduce the
runtime overhead of using Perl over the traditional programming
languages such as C.

But is Perl ready to be used for huge projects or is other languges
such as Python taking over??

What are we going to do??


-- Kasra

 

[Uri Guttman]

m> What are we going to do??

*'WE'* are going to ignore trolls like you who don't know from slow vs
fast. you can create slow programs in any language. i can write perl
that runs faster than most people can in their favorite language. you
question is useless.

uri

 

[Michael Vilain]

We hear this all too common:
"I have one huge problem with Perl; it is too slow."

But is Perl realy slow, could perl be slow at all?

The problem is that most programmers associate an implementation of a
programming
language with the language it self. The current interpreter is too
slow and hence programmers
think that 'Perl' is too slow.

Perl5 doesn't perform anything to make Perl machine like-able, Perl5
is infact hated by machines
where the Perl5 program is being executed.

Though however, with Perl6 the maintainers of the programming language
are hoping to reduce the
runtime overhead of using Perl over the traditional programming
languages such as C.

But is Perl ready to be used for huge projects or is other languges
such as Python taking over??

What are we going to do??


-- Kasra

As a recovering sysadmin, I find perl to be more than excellent at doing
the day-to-day stuff. It's my tool of choice unless I can bang
something out in the shell in 5 minutes.

As to generalized trollish comments about performance, I find it's
usually not the tool that's needs performance enhancement, it's the
performer that needs enhancement.

 

[neilsolent]

We hear this all too common:

            "I have one huge problem with Perl; it is too slow."

But is Perl realy slow, could perl be slow at all?

In my experience Perl is fast, in fact breath-takingly fast for an
interpreted language, and given the huge high-level functionality it
provides.
I don't have any benchmarks to back this up, but I think it is a known
fact that it compares reasonably to even optimised C code, performing
similar tasks. Obviously it really depends what tasks we are talking
about.
Why don't you post some simple scripts doing what you think Perl is
slow at - and show us how it can be done faster in some other language?

 

[Charlton Wilbur]

m> But is Perl ready to be used for huge projects or is other
m> languges such as Python taking over??

You might have asked this question a decade and a half ago, and gotten
an interesting debate. As it is, Perl is not only ready to be used for
huge projects, but is actually currently being used for large projects.

m> What are we going to do??

We are going to continue working on our codebases of hundreds of
thousands of lines of Perl. What are *you* going to do?

Charlton

 

[sln]

In my experience Perl is fast, in fact breath-takingly fast for an
interpreted language, and given the huge high-level functionality it
provides.
I don't have any benchmarks to back this up, but I think it is a known
fact that it compares reasonably to even optimised C code, performing
similar tasks. Obviously it really depends what tasks we are talking
about.
Why don't you post some simple scripts doing what you think Perl is
slow at - and show us how it can be done faster in some other language?

char *str = "This is a long sentence";
printf ("%s", &str[10]);

----------------

my $str = "This is a long sentence";
my @words = split ' ', $str;
printf ("%s %s", @words[3,4]);


-sln

 

[Tad J McClellan]

In my experience Perl is fast, in fact breath-takingly fast for an
interpreted language, and given the huge high-level functionality it
provides.
I don't have any benchmarks to back this up, but I think it is a known
fact that it compares reasonably to even optimised C code, performing
similar tasks. Obviously it really depends what tasks we are talking
about.
Why don't you post some simple scripts doing what you think Perl is
slow at - and show us how it can be done faster in some other language?

char *str = "This is a long sentence";
printf ("%s", &str[10]);

print substr($str, 10);

 

[neilsolent]

char *str = "This is a long sentence";
printf ("%s", &str[10]);

----------------

my $str = "This is a long sentence";

    print substr($str, 10);

--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"- Hide quoted text -

- Show quoted text -

Running these "equivalent" bits of Perl an C in a tight loop (1000000
iterations) - shows on my machine:

approx 0.3s run time for the C
approx 0.9s run time for Perl

I think this is pretty good considering Perl is interpreted and (I
suspect) the example is deliberately picked to find something C is
faster at!

 

[Uri Guttman]

char *str = "This is a long sentence";
printf ("%s", &str[10]);

    print substr($str, 10);

n> Running these "equivalent" bits of Perl an C in a tight loop (1000000
n> iterations) - shows on my machine:

n> approx 0.3s run time for the C
n> approx 0.9s run time for Perl

n> I think this is pretty good considering Perl is interpreted and (I
n> suspect) the example is deliberately picked to find something C is
n> faster at!

it also shows you have no clue about what is important these
days. development time is way more expensive than running time. you can
always get a faster computer but you rarely can speed up a development
schedule.

uri

 

[Petr Vileta \fidokomik\]

Why don't you post some simple scripts doing what you think Perl is
slow at - and show us how it can be done faster in some other
language?

char *str = "This is a long sentence";
printf ("%s", &str[10]);

----------------

my $str = "This is a long sentence";
my @words = split ' ', $str;
printf ("%s %s", @words[3,4]);

Bad!

my $str = "This is a long sentence";
print substr($str, 10);

 

[Peter J. Holzer]

We hear this all too common:
"I have one huge problem with Perl; it is too slow."

But is Perl realy slow, could perl be slow at all?

The problem is that most programmers associate an implementation of a
programming
language with the language it self. The current interpreter is too
slow and hence programmers
think that 'Perl' is too slow.

[...]
You want to see slow? Try a bad SQL join called from PHP with Firefox on
a slow one-core machine.

If you have a bad SQL join it is completely irrelevant whether you call
it from PHP or Perl or C, and whether your PHP/Perl/C code is in turn
invoked by a request from Firefox or Opera or IE. All your PHP/Perl/C
code will do is wait while the RDBMS is slogging through gigabytes of
data, and all your browser will do is wait for your PHP/Perl/C code.

hp

 

[Uri Guttman]

b> Agreed; further, algorithm developement gives
b> greater speed up than "cycle counting".

better algorithms is not the same as dev time vs cpu time. in the olden
days cpu time was expensive and programs were smaller so you had to pay
for cpu usage and it was monitored carefully. today cpu time is dirt
cheap so it is rarely accounted but programs are larger and take more
labor costs to write.

b> Jon Bentley, in a rather old book, shows a quicksort
b> in Basic on a TRS-80 outrunning a fully optimised
b> bubble sort on a Cray-1 (*)

that would also depend on the data set size. i am sure the picked a size
large enough to make that happen. you are comparing O(N log N) to O( N
** 2) and the bubble sort will grow much faster until its slow algorithm
swamps the cpu speed differences.

b> (*) I did say the book was old!

the point is still valid even if the boxes are antiquated.

uri

 

[Charlton Wilbur]

PJH> If you have a bad SQL join it is completely irrelevant whether
PJH> you call it from PHP or Perl or C, and whether your PHP/Perl/C
PJH> code is in turn invoked by a request from Firefox or Opera or
PJH> IE. All your PHP/Perl/C code will do is wait while the RDBMS is
PJH> slogging through gigabytes of data, and all your browser will
PJH> do is wait for your PHP/Perl/C code.

Which touches off another argument: even if you have a *good* SQL join,
and your database is perfectly tuned, the I/O will still probably take
an order of magnitude more time than any computation you do with the
data.

In other words: it doesn't really matter if a tight loop executes in 3
milliseconds or 10 milliseconds, if it takes 300 milliseconds before you
get the data you need to operate on from the database.

Charlton

 

[Ted Zlatanov]

UG> development time is way more expensive than running time. you can
UG> always get a faster computer but you rarely can speed up a
UG> development schedule.

There are many cases where Perl is simply the wrong tool because the
equivalent C or C++ or even assembler code would run many times faster.
Inlining the C code is not the answer if 95% of the code is
time-critical. So you write a library and call it from Perl; at that
point you're not writing code in Perl but calling it from Perl.

This is unavoidable. There will always be the need to run as fast as
possible for particular tasks, at the expense of development schedule
and whatever else falls under the carriage. This is not a Perl vs. X
problem, it's a niche that Perl and many others just don't fill.

The important thing is to realize when Perl is appropriate and when it
isn't. Unfortunately the single best way to predict this is to have
done it already, so prototyping time-critical Perl code with the real
data is really important.

Ted

 

[Nathan Keel]

char *str = "This is a long sentence";
printf ("%s", &str[10]);

n> Running these "equivalent" bits of Perl an C in a tight loop
(1000000 n> iterations) - shows on my machine:

n> approx 0.3s run time for the C
n> approx 0.9s run time for Perl

n> I think this is pretty good considering Perl is interpreted and
(I n> suspect) the example is deliberately picked to find something
C is n> faster at!

it also shows you have no clue about what is important these
days. development time is way more expensive than running time. you
can always get a faster computer but you rarely can speed up a
development schedule.

uri

Are you being sarcastic? If not, too bad, and that's scary. About 10
years ago I had some guy try and steal me away from the company I was
working at and things looked good, until he wanted to do everything in
Visual Basic and using MS Access databases over C/C++ and MySQL or
equivalent.

If you know the language, development time isn't an issue, so comparing
an experience C programmer (whom will have libraries (their own),
template scripts, etc. to re-use, unless they are an idiot) and compare
it to an interpreted language and development time, it's likely not
going to be a whole lot different. And, the compiled code, if it's
written well, will easily out perform the interpreted code.

I quickly turned down the guy's offer, because he said exactly what you
did above "If people want the program to run faster, they can get a
faster computer". That's an awful and often ignorant attitude. Never
settle for code that's inefficient for the sake of a quick turn around
time. Perl is my favorite language, but if I care about speed (and I
mean really care), I'll plan to write it in C. If you are speaking
from experience and how "in the real world", it's important to consider
that you won't get jobs if you want to create the best programs, that's
one thing, but hopefully not many people have to work for shitty
companies that are that clueless (or people above them that force them
into that situation due to lack of planning or understanding the
project). But, to each their own. I just hope I never end up having
to work for someone like that, and luckily I've always been able to
tell them to f--- off.

 

[Uri Guttman]

NK> If you know the language, development time isn't an issue, so comparing
NK> an experience C programmer (whom will have libraries (their own),
NK> template scripts, etc. to re-use, unless they are an idiot) and compare
NK> it to an interpreted language and development time, it's likely not
NK> going to be a whole lot different. And, the compiled code, if it's
NK> written well, will easily out perform the interpreted code.

study some computer history and come back when you have finished. have
you ever worked on a computer which actually accounted for your cpu
time? you don't understand my point which is well known and
supported. cpu time used to be the major expense in those days,
developer time is the major expense now.

NK> I quickly turned down the guy's offer, because he said exactly what you
NK> did above "If people want the program to run faster, they can get a
NK> faster computer". That's an awful and often ignorant attitude. Never
NK> settle for code that's inefficient for the sake of a quick turn around
NK> time. Perl is my favorite language, but if I care about speed (and I
NK> mean really care), I'll plan to write it in C. If you are speaking
NK> from experience and how "in the real world", it's important to consider
NK> that you won't get jobs if you want to create the best programs, that's
NK> one thing, but hopefully not many people have to work for shitty
NK> companies that are that clueless (or people above them that force them
NK> into that situation due to lack of planning or understanding the
NK> project). But, to each their own. I just hope I never end up having
NK> to work for someone like that, and luckily I've always been able to
NK> tell them to f--- off.

you don't get it. study some history as i said. computer power is dirt
cheap today. cheaper than you realize. developer cost is way more
expensive. so buying more/faster computers is usually more economical
than hiring more and better developers. of course this isn't always
possible but it is a very strong rule of thumb. and note, i am a speed
freak coder. most of my cpan modules (id: uri) are about doing things as
fast as possible. and they usually succeed.

for a starter, read the mythical man month.

uri

 

[Michael Vilain]

NK> If you know the language, development time isn't an issue, so comparing
NK> an experience C programmer (whom will have libraries (their own),
NK> template scripts, etc. to re-use, unless they are an idiot) and compare
NK> it to an interpreted language and development time, it's likely not
NK> going to be a whole lot different. And, the compiled code, if it's
NK> written well, will easily out perform the interpreted code.

study some computer history and come back when you have finished. have
you ever worked on a computer which actually accounted for your cpu
time? you don't understand my point which is well known and
supported. cpu time used to be the major expense in those days,
developer time is the major expense now.

NK> I quickly turned down the guy's offer, because he said exactly what you
NK> did above "If people want the program to run faster, they can get a
NK> faster computer". That's an awful and often ignorant attitude. Never
NK> settle for code that's inefficient for the sake of a quick turn around
NK> time. Perl is my favorite language, but if I care about speed (and I
NK> mean really care), I'll plan to write it in C. If you are speaking
NK> from experience and how "in the real world", it's important to consider
NK> that you won't get jobs if you want to create the best programs, that's
NK> one thing, but hopefully not many people have to work for shitty
NK> companies that are that clueless (or people above them that force them
NK> into that situation due to lack of planning or understanding the
NK> project). But, to each their own. I just hope I never end up having
NK> to work for someone like that, and luckily I've always been able to
NK> tell them to f--- off.

you don't get it. study some history as i said. computer power is dirt
cheap today. cheaper than you realize. developer cost is way more
expensive. so buying more/faster computers is usually more economical
than hiring more and better developers. of course this isn't always
possible but it is a very strong rule of thumb. and note, i am a speed
freak coder. most of my cpan modules (id: uri) are about doing things as
fast as possible. and they usually succeed.

for a starter, read the mythical man month.

uri[/QUOTE]

Uri,

I've been around since the mid-1970's and I wrote some of the accounting
packages for systems that didn't have them to charge for CPU time (the
main frame had it but the VAXes didn't, so I wrote the code to do the
accounting for the company).

As a sysadmin, I know full well any tools I write won't be for
day-to-day production use. I was the only admin that could code in C,
FORTRAN, perl, and sh. God knows where this company hired from, but
they didn't seem to hire programmers. I got all the requests for weird
stuff and updates (we've got this program that doesn't work any
more...can you look at it). My boss told me to ignore such requests.

Yes, companies can just "buy bigger computers" but at some point, that's
a waste. Guess you haven't gotten the memo that companies aren't buying
new systems right now. They want to extend the use of their systems
another couple years. You're don't seem to be bothering enough or care
enough about making something better, which is one of my criteria for
being in programming. It's good know where you stand on the mediocracy
scale. A recent slashdot article on programmers talked about a manager
trying to figure out how to balance out his team. He had a couple
really good code monkeys, about 6 hard working, get-it-done people, and
two wastes of airspace. He wanted to know what to do with those last
two. If he has an opening, maybe you should give him a call.

 

[Dr.Ruud]

you don't get it. study some history as i said. computer power is dirt
cheap today. cheaper than you realize. developer cost is way more
expensive. so buying more/faster computers is usually more economical
than hiring more and better developers. of course this isn't always
possible but it is a very strong rule of thumb. and note, i am a speed
freak coder. most of my cpan modules (id: uri) are about doing things as
fast as possible. and they usually succeed.

for a starter, read the mythical man month.

Uri, please stop wasting your precious developer's time on these types,
because they will never get it.

We could also discuss algorithms that run processes in parallel that
wastefully produce overlapping results which are then merged and deduped
in order to get the final result much much earlier then when we would
let a speed addict touch it. But we can't discuss them if we are too
busy implementing them.

 

[Uri Guttman]

MV> Yes, companies can just "buy bigger computers" but at some point, that's
MV> a waste. Guess you haven't gotten the memo that companies aren't buying
MV> new systems right now. They want to extend the use of their systems
MV> another couple years. You're don't seem to be bothering enough or care
MV> enough about making something better, which is one of my criteria for
MV> being in programming. It's good know where you stand on the mediocracy
MV> scale. A recent slashdot article on programmers talked about a manager
MV> trying to figure out how to balance out his team. He had a couple
MV> really good code monkeys, about 6 hard working, get-it-done people, and
MV> two wastes of airspace. He wanted to know what to do with those last
MV> two. If he has an opening, maybe you should give him a call.

you don't know where i stand on anything from a stupid usenet
thread. sure you can program better and get more from a cpu. i do that
all the time (as i noted about my cpan modules). it is just that some
people don't know how to do that well or don't get the
cost/effectiveness tradeoffs. and my main point (regardless of budgets)
is that development time is way more expensive than cpu time these
days. and that isn't disputed. that doesn't mean i or someone else can't
or won't write faster code. it just means that you have to look at many
ways get a faster system. i have to have strengths in scaling systems
which is not even programming but more architecture and not a common
skill. but it means i have to think in multiple dimensions including how
many cpus to buy vs how long it would take to code something up. cloud
computing is the latest way to balance this. you can rent cpus by the
minute (history repeating itself) but you need to have a distributed
architecture to take advantage of that.

so stop assuming i only push for more cpu vs better coding. i do both as
needed. but assuming that better development is the only solution for
more speed is just as dumb as the other way around. knowing their true
costs and balancing is the issue.

uri

 

[Uri Guttman]

R> Uri, please stop wasting your precious developer's time on these
R> types, because they will never get it.

R> We could also discuss algorithms that run processes in parallel that
R> wastefully produce overlapping results which are then merged and
R> deduped in order to get the final result much much earlier then when
R> we would let a speed addict touch it. But we can't discuss them if we
R> are too busy implementing them.

agreed. 'nuff said.

but my point about reading MMM is still very valid!

uri