 |
BorlandTalk.com Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Scout Guest
|
Posted: Sat Jun 24, 2006 8:12 am Post subject: Speed is only what you think it is |
|
|
After reading posts about native Win32 vs .Net code performance, I
feel compelled to rant...
Recently, a very large Delphi application that I have written was
given a test to confirm that it would perform adequately under the
expected load and provide accepatble response times.
My app was also compared with the app it replaces.
I took no part in the test. I didn't even know that it had been
conducted until the inevitable comparison of statistics started.
My app was built with BDS2006 using the Delphi personality.
The conclusions reached were somewhat interesting:
#1: My app's performance was acceptable with the hardware in use and
the expected load.
#2: My app used more processor resource than the app that it was
designed to replace, but responded more quickly.
#3: My app used less memory than the app it was designed to replace.
#4: My app generated less network traffic than the app it was
designed to replace.
Eventually I was asked to explain why my app was so processor hungry.
Given that the various resources in use are scarce, I came up with
this:
The network is a slow shared resource so my app makes as little use of
it as possible.
Disk memory is very slow compared with RAM, so I use RAM instead of
disk wherever posssible.
By eliminating (or minimizing) the bottlenecks that can make the
processor wait on I/O, my app uses the maximum amount of processor power
available for a very small period of time, so it makes sense that it is
processor hungry.
By assembling a job in such a way that it becomes processor-bound for
a brief instant, the job is handled more efficiently, and ultimately
uses less processor resource than the alternatives.
Since I'm using the native Delphi Win32 compiler, there's a good
chance that the processor can just churn through i86 instructions and
produce a result within the brief period that I am hogging it.
My app does no tricks with thread priority. There are no strange
optimizations. All it does is take a user request and turn that into
something that can be submitted to a server in such a way that the
server can just get on with its job.
Imagine how short the lines would be at the DMV if everyone turned up
with the correct documentation. That's all my app tries to do.
Currently my app wins over its alternatives by NOT having to deal with
Patti and Selma Bouvier.
Scout |
|
| Back to top |
|
 |
Scout Guest
|
Posted: Mon Jun 26, 2006 8:11 am Post subject: Re: Speed is only what you think it is |
|
|
In article <vyys47iz287y$.dlg (AT) dlg (DOT) marcrohloff.com>, "Marc Rohloff
[TeamB]" <"on request"> says...
| Quote: | On Sat, 24 Jun 2006 18:18:43 +1200, Scout wrote:
#2: My app used more processor resource than the app that it was
designed to replace, but responded more quickly.
Put what about throughput per resource?
i.e. if your app responds 3 times as fast, but only uses twice the
resources then surely that is an improvement.
I guess that was my point (sorry if I didn't make it clearly). |
In reality it would respond 8 times as fast but only used twice the CPU
while it was doing its work.
By my maths, that means that my app used 1/4 of the resource of the one
it was to replace. Faster but hungrier.
Scout |
|
| Back to top |
|
 |
Scout Guest
|
Posted: Mon Jun 26, 2006 8:11 am Post subject: Re: Speed is only what you think it is |
|
|
In article <449f2073$1 (AT) newsgroups (DOT) borland.com>, bwatters (AT) geometrix (DOT) bc.ca
says...
| Quote: | Scout,
#2: My app used more processor resource than the app that it was
designed to replace, but responded more quickly.
Eventually I was asked to explain why my app was so processor hungry.
A simplier explanation. CPU cycles are free. Is there any reason one would
not want to use the entire CPU when it otherwise isn't being used by
something more important? Is there any reason that the system idle task
should be given more processor time when you are actually doing something?
CPU cycles aren't free, but by eliminating the sleep and task-switch |
cycles while my app WASN'T waiting for I/O, it looked like my app was a
terrible CPU hog.
Not waiting for I/O means no thread-stalls, fewer thread switches and
an effective boost in performance although the CPU usage looks bad.
Overall, the system responds better and doesn't run as hot.
I guess it comes down to lies, damn lies, and statistics.
I would much rather that my app be a cpu hog instead of an I/O hog.
With modern CPUs, I/O is many millions of times slower. All I tried to
do was eliminate the I/O wait time.
I realize that any I/O request is going to consume a certain amount of
processor resource, but by not spin-locking on I/O, the total processor
usage is reduced.
I guess that it is academic about how a program should be structured
to take advantage of the physical parts of a computer, and a true
machine abstraction should ignore these, but in the real world it is
surely a better idea to acknowledge that RAM is many orders of magnitude
faster than disk, and CPU and CPU cache are many orders of magnitude
faster than RAM.
Once you acknowledge this, you can optimize your programs to take
advantage of the discrepancy. Even Delphi programs.
I still think that the worst thing you could ever do is try to take
advantage of RAM speed over disk speed in a Delphi program until you
have identified that those are the bottlenecks. Usually the algorithm
is the bottleneck, and only a profiler will tell you that you are wrong.
Sometimes, common sense can tell you that you've got it wrong:
How many round-trips am I doing to the server?
If I get the server to send redundant data (and create more network
traffic), am I winning when I DO need that otherwise redundant data and
another round-trip is not required?
How often is that redundant data actually needed? 1% of the time -
maybe don't send it, 30% of the time - always send it. The threshold is
going to be app specific, but a round-trip is so much more expensive
than redundant data transmission that it may be worth it.
Scout |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|