|
|
Posted by Chung Leong on 01/19/06 02:33
Iván Sánchez Ortega wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> As you may already know, refactoring is almost always a good idea, as it
> reduces complexity of the algorithm, procesing time, and increases the
> cache hit ratio, to name a few consecuences.
I don't know what refactoring has to do with this, but since you
mention it, I'll give you my 2 cents. In the real world, refactoring is
always a bad idea. By definition, you are not adding new
functionality--hence value to the product. You are thus wasting
programming and QA resource. Moreover, you risk introducting bugs into
what was working before. It's a lose-lose proposition.
As every good engineer knows, if it ain't broken, don't fix it.
> Less complexity, less CPU time, less memory, less code. Any developer that
> has been taught anything about algorithms knows that. You'd better have a
> good reason to not refactorize your code in this way.
There are plenty of good reasons. Interleaving data retrieval and
processing in the manner you describes makes it hard to properly
modularize the code. You are also fixing the direction by which the
rows can be processed--the sorting order of the query--without the
possibility of looking ahead.
> That's not a bad idea for batch jobs, but is a terrible one when you have
> tenths, hundreds of hits per second. A few MB of memory per script may seem
> a small issue, but think about a few MB per script, 100 scripts per second.
> A "short time" is not a big thing, but a "short time" hundreds of times per
> second is.
That's just unrealistic. When you retrieve data from the database, it
usually goes somewhere--i.e. to the client. In you scenario you'd have
a server that output multiple gigs per-second. I don't know about you
but I certainly don't have a peta-byte bandwidth quota.
Navigation:
[Reply to this message]
|