|
in reply to Re: Faster Perl, Good and Bad News
in thread Faster Perl, Good and Bad News
dws
I think you are saying something similar to what has been said, but in a more complete way. These are things to do for performance tuning; to get your script to run in a "sweet spot" of memory/cpu usage.
The only reason I even put in the bit about starting with a c data structure is for those who re-write all their code to help them tune it to run the best that it can.
You have to put work in to get these performance savings to happen, so I don't expect people to use it pass the point at which things run the best for them. Now I'm having to tune this for two machines, one with 128 megs of ram and 700 mhz pIII processor, and a pII 300 mhz with 212 megs of ram. With those limits, I stopped trying to optimize after I got under the requirements of both systems (running in a reasonable time on one, and not using the swap disk on the other.) Perhaps this would have been better titled as tips and tricks for perfomance.
Personally, I think the real gem is the recursive calls in c, mainly becuase I didn't find any good examples of recursing a perl data structure in c, until I asked here.
Now then, I'm going to sit in the corner and put my thumb in my mouth, to try to keep my foot out of it. |
Re^3: Faster Perl, Good and Bad News
by dws (Chancellor) on Aug 09, 2002 at 23:01 UTC
|
Now I'm having to tune this for two machines, one with 128 megs of ram and 700 mhz pIII processor, and a pII 300 mhz with 212 megs of ram.
Something else to consider when optimizing: What is the cost , compared with the cost of implementing various solutions. Multiply the time it takes you to develop an XS-based solution times the cost of your time, and compare this to the cost of adding memory to these machines. You can add a 128Mb stick to a box for < 75 USD right now.(Granted, once you factor in overhead in including purchasing and labor, it costs an organization more this.)
It may well be that capital budget is difficult where you work, and that throwing your time at the problem is less expensive. But this is still a calculation that you and your management (or management equivalent) need to make.
| [reply] |
|
|
You can add a 128Mb stick to a box for < 75 USD right
now.(Granted, once you factor in overhead in including
purchasing and labor, it costs an organization more this.)
dws++ for bringing up the issue of adding hardware
(there are many ways of making code fast enough, one of
which is throwing Moore's Law at the problem), but if this
code's running on a production machine, the cost of adding
hardware may be astronomically higher than $75USD once you
factor in the cost of downtime. If you don't have a hot
failover box, you'll have to shut down the machine for at
least a couple of minutes, and in my experience this sort
of trivial upgrade ("we're just adding another stick of
RAM, what could go wrong?") is exactly the kind of thing
that ends up lasting for hours and generating infinite
Angry Customer Calls. If that $75 stick of RAM ends up
losing you a $100,000 contract, you might have been better
off paying a programmer to spend a day profiling,
optimizing, and documenting the code.
I realize that your response was much more
sophisticated than just "hardware's cheap, throw hardware
at it", but not all costs are obvious, and it's often a
mistake to look only at first-order costs. (This happens
with a lot of hardware purchases: buying that cheap KVM
switch costs you a lot of money when it dies just before
a major outage, for instance.)
That said, if you're running into hardware walls like
this on a regular basis, it's probably time to upgrade
somewhere in the near future -- like your next maintenance
window.
(And without bringing in a straw-man argument, let me
just mention that there are some places -- hospitals, for
instance -- where downtime costs more than just money.)
--
F
o
x
t
r
o
t
U
n
i
f
o
r
m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!
| [reply] |
|
|
A few years ago, my boss at the time came to me one day and said, "Don't make your self indespensible to me, cos if you do, I'll have to sack you!".
The relevance in this thread?
Any single machine that is so indispensible that it being down can cost $100,000, should be done away with, forthwith.
Why? Cos one day--sooner rather than later, and despite air-condition rooms, premium-grade, tested components, regular maintainance and all the TLC in the world--it's gonna fail. And Murphy's law, it's gonna do it just as that $100,000 contract is being finalised.
| [reply] |
|
|
|
|
|
|
