Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re: Performance, Abstraction and HOP

by Tanktalus (Canon)
on Aug 31, 2005 at 21:37 UTC ( #488237=note: print w/replies, xml ) Need Help??

in reply to Performance, Abstraction and HOP

A pedant, perhaps, but an important one to me. Performance doesn't matter. Never has, never will. Responsiveness is what matters. Often one must improve performance to get responsiveness, but performance is never important of itself.

For example, if you have some sort of server (whether that be web or otherwise) which can handle 1000 actions per minute, and then you improve the performance to 2000 actions per minute, you've no doubt improved performance. But if there are only 500 actions to perform per minute, then those 500 actions are unlikely to have had a resultant boost in responsiveness. And you've just wasted a bunch of effort. However, if you sometimes have a peak of 1500 actions to perform per minute, then that increase in performance will ultimately mean better responsiveness during that peak.

I don't care that it takes my word processor 1.5 million or 1.5 billion cycles to handle the typing of 5 characters - I have 3 billion cycles per second, the responsiveness of the system won't suffer.

What does that mean to abstraction? Lots. It means that if the system is still responsive when I use more abstraction, then I can save money on programmer time, which will make my system cheaper (theoretically, this would allow the program to be cheaper to produce, either meaning layoffs or more time-enhancing features for the same cost).

You do need to be aware of responsiveness. For example, let's take a database at a bank. It's critical that everyone standing at ATMs, whether your own or your competitors in the same network, can access their cash within a couple of seconds. Most of this time is eaten up by latency, so fast data retrieval is of utmost importance. Yet, the overnight daily summaries given to the executives can take 6 hours to complete and be perfectly responsive.

The biggest difference in my mind between performance and responsiveness is the focus. Performance focuses on code, computing, and programmers. These are always the wrong things to focus on. Responsiveness focuses on customers and users. These are always the right things to focus on. Rather than saying, "I need to get 2000 actions per minute", you need to say, "I need to ensure I can get all 1500 users each minute, at peak volume, their information calculated within 2 seconds of their request." And on the topic of databases, there are tools available to ensure different queries get different priorities to ensure time-critical get more system resources than large reports - I know IBM has their own DB2-branded version, and am guessing that other vendors either have their own, too, or third-parties are providing them. But it's an idea that is focused on the right area: applying the system to the right job at the right time. Focusing on responsiveness, not performance.

Replies are listed 'Best First'.
Re^2: Performance, Abstraction and HOP
by xdg (Monsignor) on Aug 31, 2005 at 23:23 UTC

    I agree in part, but I think this is too narrow a view of what "performance" means or should mean. In my opinion, performance is multi-dimensional and it can only be defined from the point of view of the user/customer/business. That is where focus is critical.

    Reponsiveness is merely one kind of performance measure. Another measure might be agility or adaptability (e.g. the turnaround time for necessary changes to the codebase to be rolled into production). This matters for things like new product development where new products have large impacts on existing systems and processes and time-to-market is critical for competitiveness.

    From that perspective, if agility is one of the performance metric, then abstraction may be a useful tool at incresing agility, despite a cost in responsiveness. Or at least, improvements in agility must be traded off against costs in decreased responsiveness. Other metrics might include ongoing maintenance costs, which again might mean a different tradeoff between speed of execution and abstraction.

    People shouldn't get so caught up searching for a nail for their hammer, whether that's "efficiency" or "abstraction". There is no one universal tool -- it takes a whole toolbox, properly applied to the task at hand, to deliver a valuable solution.


    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re^2: Performance, Abstraction and HOP
by pg (Canon) on Aug 31, 2005 at 23:20 UTC

    Lots of applications today are interactive, and for those applications, peformance is mainly measured by the response time. One thing we have different idea is that, I don't see responsiveness as something different from performance, but rather one way of measuring performance. Other than that, we are mostly on the same page.

Re^2: Performance, Abstraction and HOP
by tirwhan (Abbot) on Sep 01, 2005 at 09:08 UTC

    This is only true if you can hog the system. Application programmers often fall into the dangerous mindset of believing that their application is the only thing that matters and therefore it is ok to e.g. temporarily use all the memory a current machine can reasonably be expected to have.

    Every single machine I've worked on for the last 15 years runs multiple independent applications at the same time, regardless whether this is a server or desktop. If one of the apps consumes an undue amount of system resources to the detriment of other apps, I'll be keen to look for an alternative. In the context of your post, if your app can now performs 2000 actions per minutes as opposed to 1000 actions before, it is highly likely that the 500 required actions will be performed using less system resources than before and this can be worthwhile although there is no measurable change in responsiveness.

    So IMO performance does matter beyond responsiveness requirements if you consider resource consumption per action an element of performance. All the usual caveats (premature optimization is the root of all evil, profile before you optimize, developer time vs.optimization gains etc.) apply, of course.

      I see this, too. The billing mediation server at our telecom company is powerful, but runs so many applications that it can get backlogged... and backlogs can be dangerous when data keeps rolling in.

      Of course, the main reason we have a backlog is because we invoke multiple Java Virtual Machines. So then, poor responsiveness is due to poor environment or design considerations, or something like that.

      Now, the operations guys tell us that if perl was the runtime chosen, there would have been no backlog. But apparently, Perl isn't Buzzword Compliant :(
Re^2: Performance, Abstraction and HOP
by jcoxen (Deacon) on Sep 01, 2005 at 12:31 UTC
    There was a study done several years back that determined that, if a given program took more than X seconds to respond to user input, it was considered "slow" regardless what was happening behind the scenes or how fast the program actually was. Because of this perception, calculation intensive programs like spreadsheets are so that the information that is currently displayed is recalc'd immediately. The rest of the spreadsheet (the part that is not currently displayed) is recalc'd as a background task. Similar gymnastics are done with indexing on interactive database programs, repagination in word processor, etc.

    So, the program appears to be faster - and more responsive - than it actually is.

    Just some food for thought.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://488237]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2020-11-24 10:25 GMT
Find Nodes?
    Voting Booth?

    No recent polls found