Re: [guilt] Taking too much CPU cycles
Re: [guilt] Taking too much CPU cycles
- Subject: Re: [guilt] Taking too much CPU cycles
- From: Scott Ellsworth <email@hidden>
- Date: Sun, 23 Nov 2003 01:07:00 -0800
On Nov 19, 2003, at 2:58 PM, Erik Hanson wrote:
On Nov 18, 2003, at 11:14 AM, Rob Kuilman wrote:
What do the programmers here do, to make their applications as
optimized as possible?
1. Determine performance goals [...]
2. Write tests that verify those performance goals (and of course run
those tests often along with the rest of your test suite).
3. When a test fails, fix the performance, but just enough to get the
test passing again.
Let me add another step, and one often forgotten by developers.
Every now and then, take the relevant parameters from your performance
tests, multiply them by an order of magnitude, and see how your app
performs. This may not imply any test changes, but can be very
valuable data for planning the future.
For example, if one of your goals is "process at least 10,000 records
in 5 seconds", try processing 100k records. Or perhaps a million.
If you find that processing ten or a hundred times as much data takes
ten or a hundred times as long, then you are to some extent future
proofed. The greater speed of hardware/larger disks/larger RAM
partitions will make your app more able to handle data that the
customer of the future will see.
If, on the other hand, you find that ten times as much data takes a
hundred times longer to process, you might have an as yet unknown n^2
algorithm in your code. This often means that your app will need to be
revisited in the near future. You may still want to hold off on
optimizing, because you have already gotten requirements in step 1, but
this data lets you know which changes are going to cost as the
requirements shift.
Also, when Optimization Day comes, this is the kind of optimization
that really pays off - making the overall code faster by choosing
better ways of handling the problem tasks. Micro optimizations tend to
make code more complicated; better algorithms make it easier to
understand.
(This is the voice of experience. Requirements do change, and it is a
lot easier to go into a meeting with some hard figures about what such
a change will cost, and whether the new, larger, dataset/image is a
minor problem, or a total change of project scope.)
Scott
email@hidden
Java, Cocoa, WebObjects and database consulting
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.