Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Perl is too slow - A statement

Reply
Thread Tools

Perl is too slow - A statement

 
 
Peter J. Holzer
Guest
Posts: n/a
 
      04-28-2009
On 2009-04-27 21:14, cherryplankton <(E-Mail Removed)> wrote:
><(E-Mail Removed)> wrote:
>> 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
 
Reply With Quote
 
 
 
 
Uri Guttman
Guest
Posts: n/a
 
      04-28-2009
>>>>> "b" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:

b> Uri Guttman wrote:

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


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

--
Uri Guttman ------ http://www.velocityreviews.com/forums/(E-Mail Removed) -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
 
Reply With Quote
 
 
 
 
Charlton Wilbur
Guest
Posts: n/a
 
      04-28-2009
>>>>> "PJH" == Peter J Holzer <(E-Mail Removed)> writes:

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


--
Charlton Wilbur
(E-Mail Removed)
 
Reply With Quote
 
Ted Zlatanov
Guest
Posts: n/a
 
      04-28-2009
On Mon, 27 Apr 2009 11:58:56 -0400 Uri Guttman <(E-Mail Removed)> wrote:

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
 
Reply With Quote
 
Nathan Keel
Guest
Posts: n/a
 
      04-29-2009
Uri Guttman wrote:

>>>>>> "n" == neilsolent <(E-Mail Removed)> writes:

>
> >> > char *str = "This is a long sentence";
> >> > printf ("%s", &str[10]);
> >> > ----------------
> >> > my $str = "This is a long sentence";
> >> 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
>


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.
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      04-29-2009
>>>>> "NK" == Nathan Keel <(E-Mail Removed)> writes:

NK> Uri Guttman wrote:

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


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

--
Uri Guttman ------ (E-Mail Removed) -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
 
Reply With Quote
 
Michael Vilain
Guest
Posts: n/a
 
      04-29-2009
In article <(E-Mail Removed)>,
Uri Guttman <(E-Mail Removed)> wrote:

> >>>>> "NK" == Nathan Keel <(E-Mail Removed)> writes:

>
> NK> Uri Guttman wrote:
>
> >> 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.

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


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.

--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]


 
Reply With Quote
 
Dr.Ruud
Guest
Posts: n/a
 
      04-29-2009
Uri Guttman wrote:

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

--
Ruud
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      04-29-2009
>>>>> "MV" == Michael Vilain <(E-Mail Removed)> writes:

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 ------ (E-Mail Removed) -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      04-29-2009
>>>>> "R" == Ruud <(E-Mail Removed)> writes:

R> Uri Guttman wrote:
>> 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.


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

--
Uri Guttman ------ (E-Mail Removed) -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: slow slow slow! Expert lino fitter Computer Support 5 12-12-2008 04:00 PM
Re: slow slow slow! Beauregard T. Shagnasty Computer Support 2 12-10-2008 09:03 PM
Re: slow slow slow! Expert lino fitter Computer Support 0 12-10-2008 02:33 PM
Effect.SlideUp is too slow--next statement executes immediately nolo contendere Javascript 7 11-09-2007 08:44 PM
Problems with imaging (too slow or too much RAM) SB Java 0 08-05-2003 11:06 AM



Advertisments