I thought about just replying to your email with the one-liner "I
respectfully disagree", but, considering the anger between the lines, I
would rather say, ...
Hey, eyck, take it easy. This is not supposed to be an emotional issue.
>and the speedup would be on the order of speedup gained by the
modification proposed here.
Which is a proposed roughly 25%, not orders of magnitude, and then only
during the initial extraction process. Not during the normal running of
the application.
>I'm having problems on 3.4Ghz Xeons
We have no trouble with speed problems on old, second-hand 733Mhz
Pentium-III machines. Well, other than the fact that they are
comparitively slow to begin with. If you have a trouble on a 3.4Ghz
Xeon there is definitely something wrong. Does your your application
really have so much code that a 3.4Ghz Xeon will not help your
application come up to speed in a reasonable amount of time? I think
perhaps you were just venting some anger.
>cost to upgrade them
Here is some sarcasm of my own: If you really would consider spending
all that time and money for a 25% decrease in time for your application
coming up to speed, you are obviously not in management. In reality
your application could be life-critical, in which case the need for
speed would push you into coding with C, Ada, or some other
faster-execution-time compiled language.
>delays longer then 0.2s as annoying,
An old study from the then Singer-Link (think flight simulators) company
found the number to be around 50 milliseconds, not the 200 that you
mention. And yes, startup speed is annoying to a user. However, users
are used to the startup speed of, say, Microsoft Word, Open Office, and
so on. When comparing the multiple seconds that they take, the multiple
seconds that PAR/pp takes does not seem unreasonable. Yes, a faster
machine would be faster, a slower machine slower, but comparatively
speaking, the relative times are what end users see.
>startup partly depends on disk io/mem io
Yes, but the 25% figure was obtained in two tests from the same machine,
wherein the disk speeds, etcetera were all the same. We are not talking
about adding or taking away any significant amount of code, so the time
off or on the disk, and other such things, should remain constant given
the same machine.
>Cool, very nice for maintainability - re-design the whole app because
of easily avoidable performance problem.
Anger management questions aside, are you really suggesting that there
are applications that would have you "re-design the whole app" if PAR/pp
is not changed to pick up the said 25% startup speed?
Again, I think you just wanted to vent some anger. Still, you raise
points that are brought up from time to time in different forums. The
discussions usually are about testing, maintainability, time available,
programmer capabilities, profitability and so on. A good book on such
things is called "Joel on Software". The full title is:
"Joel on Software: And on Diverse and Occasionally Related Matters That
Will Prove of Interest to Software Developers, Designers, and Managers,
and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in
Some Capacity (Paperback) "
I realize that one can have read many such books and still respectfully
disagree.
Thanks
eyck wrote:
This might sound like passing the buck but processors are getting so
fast now, and are due to get faster. The extra speed would help with
I'm having problems on 3.4Ghz Xeons, have you got any idea how much it
would cost to upgrade them to say Woodcrests? Add logistical costs,
downtime for upgrade, licensing issues...
..and the speedup would be on the order of speedup gained by the
modification proposed here.
old machines, but I am not sure a saved half second or so would be much
It is generaly assumed that when it comes to user interface, humans
perceive delays longer then 0.2s as annoying, and startup of app is one of
main user-visible delays.
Plus, startup partly depends on disk io/mem io, so you can't talk about
faster CPUs bringing any significant changes to those.
So, when your pp'ed app starts in 7s, and you wan't to bring it down to
under 0.2s, you need 2 orders of magnitude faster system. There are no such
systems available today, and won't be for forseeable future.
need I imagine the original programmer would simply design the program
to stay running, and have a "run again" button, or some sort of similar
Cool, very nice for maintainability - re-design the whole app because of
easily avoidable performance problem.
