• Post Reply Bookmark Topic Watch Topic
  • New Topic

when to focus on performance.

 
chris coleman
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A question for the author Jack. (All others are welcome to respons also.)
Suppose you think of the lifecycle of development. What would you say are the times to focus on performance in the system? I am wondering what you would say to this question.
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well...

How does a project get to be a year late?. One day at a time.
--Mythical Man Month, page 153

What Brooks means is that there's rarely a lynchpin slowing everything down. Do not expect to run a profiler at the end of the project and then discover that .1% of the code is taking 70% of the time (although I actually did see this happen on one project). You need to be constantly watching the performance over the lifecycle of the project.
On the other hand, don't bother optizming right away. Most of the time the code will change anyway and your optimizatins will go to waste.
In short, there's no clear answer, e.g. at 54.7% of the way through the project, start to optimize. I recommend starting about 1/3-1/2 way into the project start to run performance tests just for informational purposes. Obviously as you add more funcitonality, things will get bigger/slower. That's normal. What this will do it help you catch big jumps, e.g. the Foo algorithm has been getting 2% slower a week on average, but last week it got 15% slower. Then you can investigate and decide if that is appropriate (lots of new functionality), or if its a problem, and if the latter, whether to deal with it now, or simply note it as a toruble spot to be revisited later.
--Mark
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my humble opinions, there only very few performance issues you need to fully resolve early in development - those which are hard/costly to change later (choice of programming language comes to mind).
For the other things it suffices to properly encapsulate them in your design, so that they are easy to exchange if they prove to be really an issue. Than you can implement them in the simplest way instead of the fastest.
The saved time for implementing, testing, debugging and maintaining the solution will typically easily suffice to exchange the few things which *really* prove to be an issue.
 
Jack Shirazi
Author
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are different things to look for at different stages. It's important to look for performance issues at the design stage, especially those of shared resources. At implementation, you shouldn't performance test until after the units are stable, since functional changes will invalidate any tests you do.
I wrote an article covering the basics of what to focus on and when: Performance Planning For Managers
--Jack Shirazi
JavaPerformanceTuning.com
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!