LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (September 2003, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Tue, 9 Sep 2003 09:45:21 -0700
Reply-To:   cassell.david@EPAMAIL.EPA.GOV
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   "David L. Cassell" <cassell.david@EPAMAIL.EPA.GOV>
Subject:   Re: Index performance question
Content-type:   text/plain; charset=US-ASCII

Michael Raithel <RAITHEM@WESTAT.COM> replied [in small part]: > Richard, that is _MOST_ strange behavior, indeed! I would _LOVE_ to know > what operating system you are running this SAS application on. > . . . . > From what you describe, it is almost as if SAS is "reclaiming" the index > buffers from your previous DATA steps. > . . . .

I was wondering the same thing myself, Mikeeeeee. It seems to me that there is another possibility. The OP may be using caching controllers for his hard drives, and the information may still be cached in the RAM of the controller so that the OS is handed the info without having to go hunt on the drive again.

But (if this wild, unsubstantiated speculation is true) this means that an early DATA _NULL_ to get the info into the controller cache won't help when more work is done later, obliterating the controller cache with new data from different drive sectors. This leads to a logical test. The OP can do the same test as before, but adding a fast read of, say, the first 2 Megs of the file in between the early indexing and the second indexing. We might see the time required to do the second index suddenly jump back up to what we would normally expect.

David -- David Cassell, CSC Cassell.David@epa.gov Senior computing specialist mathematical statistician


Back to: Top of message | Previous page | Main SAS-L page