Joe Van Dyk wrote:
> Marshall wrote:
>
>> Joe Van Dyk wrote:
>>
>>> Mikito Harakiri wrote:
>>>
>>>> Robert, you claim 35 years of application programming experience. Have
>>>> you ever come across a performance problem when database is accessed
>>>> via API
>>>>
>>>> getItemIdList
>>>> getItemDetail
>>>>
>>>> so that a single jsp page issued a hundred SQL statements instead of a
>>>> single one? Come on, this one is so common that it surfaces on every
>>>> performance meeting.
>>>
>>> This problem is easily solved via caching.
>>
>> This is like saying: we have a big pile of dirt on our expensive
>> Persian rug; what shall we do? That problem is easily solved
>> by covering the dirt in a layer of palm fronds.
>>
>> Caching certainly has its place in the set of tools used
>> to solve performance problems. And its place is exactly:
>> the tool of last resort. When everything else has failed,
>> you cache. I don't know why it's so often the *first* thing
>> that junior programmers come up with; maybe because
>> it's easy to understand, and solving the actual problem
>> requires some effort.
>>
>> The *best* way to solve the performance problem that
>> Mikito describes is to rewrite the object-at-a-time code
>> into set-at-a-time code, which will necessarily perform
>> much faster. Unfortunately OOPLs encourage object-
>> at-a-time thinking, so it's hard for OO programmers to
>> learn this lesson. I try to repeat it at every team
>> meeting, which is not usually a problem because
>> somewhere in every meeting someone will propose
>> papering over a performance problem by caching.
>>
>> Marshall
>
> I think the *best* way depends on the particular issue at hand. However,
> I don't possess the mental aptitude necessary to make blanket statements
> about what's best for all web applications.
>
> In RubyOnRails, I probably would create a instance variable in the
> Controller that contains the data from one SQL statement (perhaps
> automatically generated in the Model), and use that data in the view.
> I'm sure that's horrible and won't work. All those applications out
> there that I've written are probably busy crashing and corrupting data,
> as I'm using objects and escapulation or something.
False dichotomy is fallacious reasoning. If your programs crash, I
suggest it has more to do with the way you reason than what tool you used.
Received on Thu Jun 01 2006 - 18:45:35 CDT
