Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
From: Joe Van Dyk <joe.vandyk_at_boeing.com>
Date: Thu, 1 Jun 2006 22:49:34 GMT
Message-ID: <J07E2M.M5_at_news.boeing.com>
>
>
> 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
>
Date: Thu, 1 Jun 2006 22:49:34 GMT
Message-ID: <J07E2M.M5_at_news.boeing.com>
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.
Joe Received on Fri Jun 02 2006 - 00:49:34 CEST