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 2000, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Mon, 11 Sep 2000 14:55:18 GMT
Reply-To:   "John M. Wildenthal" <jmwildenthal@MY-DEJA.COM>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   "John M. Wildenthal" <jmwildenthal@MY-DEJA.COM>
Organization:   Deja.com - Before you buy.
Subject:   Re: Disastrous performance in V8 cf V6

In article <39bac689.1728385@news1.inter.nl.net>, A.Bouwmeester@inter.nl.net (Aswin) wrote: > This problem is not memory related as some suggest but I/O related. I > do not know the cause, but this is how it works: > SAS datasets are paged, each page can contain multiple obs. When > reading data from disk it is done page by page, not obs by obs. So if > you want one obs SAS reads a whole page. If you want another one that > is in the same page, there won't be any I/O. If you want a second > that's not on the same page, there is I/O. > If you use an index to access the data it is not very likely that > subsequent obs are an the same page, most obs require a new page to be > read. In the end pages are read multiple times, could be as often as > there are obs in a page. If the data was sorted you would be sure that > each page will be read only once. > Conclusion: Indexed data access can result in suboptimal I/O. > > Some hints > -Pagesize can be set using bufsize option > -Pagesize and number of observation in a page can be queried using > proc contents > > Aswin

Wouldn't BUFNO also be somewhat useful? Would setting it up to 16 or 64 or some appropriate number N force SAS to effectively cache the last N pages?

Sent via Deja.com http://www.deja.com/ Before you buy.


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