dcest61 at hotmail.com
Thu Jun 11 02:06:08 CEST 2009
Jeff M. wrote:
> On Jun 9, 9:08 pm, Arved Sandstrom <dces... at hotmail.com> wrote:
>> Jon Harrop wrote:
>>> Arved Sandstrom wrote:
>>>> Jon, I do concurrent programming all the time, as do most of my peers.
>>>> Way down on the list of why we do it is the reduction of latency.
>>> What is higher on the list?
> IMO, that response is a bit of a cop-out. Correctness is _always_ most
> important, no matter what application you are creating; without it,
> you don't have a job and the company you work for goes out of
> But, assuming that your program works and does what it's supposed to,
> I agree with Jon that performance needs to be right near the top of
> the list of concerns. Why? Performance isn't about looking good as a
> programmer, or having fun making a function run in 15 cycles instead
> of 24, or coming up with some neat bit packing scheme so that your app
> now only uses 20K instead of 200K. Performance is - pure and simple -
> about one thing only: money.
> Programs that use more memory require more money for the hardware of
> every user. Programs that run slower eat more time per day. If you
> have 100,000 users, all doing an operation once per day that takes 20
> seconds, being able to shave 5 seconds off that saves 5.78 man-days of
> work. Hell, for some applications, that 20 seconds is just startup
> time spent at a splash screen. Just imagine if every Google search
> took even 5 seconds to resolve, how much time would be wasted every
> day around the world - ignoring the fact that Google wouldn't exist if
> that were the case ;-). Obviously Google engineers work incredibly
> hard every day to ensure correct results, but performance better be
> right up there at the top of the list as well.
> Jeff M.
Point taken, but I primarily work on internal government and corporate
applications. Might be hundreds or thousands of users at any given time,
but not typically tens or hundreds of thousands. Hundreds or thousands
of users translates to at least an order of magnitude less
"simultaneous" users. Ops people that I talk to who monitor apps I've
worked on, or similar apps, rarely report any such where the application
itself is presenting a sluggish aspect to users because it's stressing
out processors, or consuming gargantuan memory.
Typically when latency problems come up, it's because the app has to
talk to other servers - databases, LDAP, print servers etc. In other
words, the network is coming into play. In fact when we do work on
performance, it's typically about minimizing calls to the database or
More information about the Python-list