RE: SQL vs. traditional I/O?

midrange-l-bounces+markp=softlanding.com@xxxxxxxxxxxx wrote on 07/23/2004 
04:43:03 PM:

> > From: Vern Hamberg
> > 
> > Joe, it's not really caching, it's just the result of data being in
> memory
> > that is available to all processes. Unit testing would need you to
> CLRPOOL
> > and SETOBJACC *PURGE in order to compare apples to apples. Another
> kind of
> > testing would be what you are doing now, to show what happens when you
> > leave things in memory.
> 
> Um, why would I need to CLRPOOL to compare "apples to apples"?  Are you
> saying that somehow CLRPOOL will make SQL run better?  Why?  Does SQL
> not know how to take advantage of memory?  If so, that's a knock on SQL,
> not my testing.  Since I would never be doing a CLRPOOL in production,
> why would I do it in a test?
> 
> Just trying to find out what you consider "apples to apples" to really
> mean.
> 

Joe,

For the way that you have presented the data and your actions so far, you 
are correct.  The increase in performance on subsequent runs is indeed a 
benefit to native I/O that should not be factored out of the tests.  They 
probably indicate that if one were modelling a multi-user situation where 
the same code is being run in multiple jobs, that the native I/O solution 
may provide an even greater benefit over SQL than these single-run tests 
demonstrate.

On the other hand, a valid point that Vern might be raising is that when 
you make changes to the test code you should probably run these commands 
to clear out memory before starting a new test suite so that there is no 
residual caching from previous runs that skew the results of the new 
tests.

Mark