Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: tsm@hou2d.att.com (Thomas S Magg)
Newsgroups: comp.sys.sun
Subject: RAM-DISK or SMART-CACHE for SPARCII running UNIX
Keywords: Software
Message-ID: <2006@brchh104.bnr.ca>
Date: 19 Mar 91 18:33:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 33
Approved: Sun-Spots@rice.edu
X-Original-Date: Thu,  7 Mar 91 20:08:37 EST
X-Sun-Spots-Digest: Volume 10, Issue 59, message 1
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

I'm looking for the PC/DOS/WINDOWS RAM-DISK equivalent for a SUN SPARCII
running UNIX.  Does anyone know if such an item exists?

Specifically we have an application written in C++ that accesses a 20MB
file extensively.  Using benchmarks we determined that the I/O from the
20MB file was causing a performance bottleneck ie. to draw a configuration
map took: 1 second to set-up, 32 seconds to read the configuration from
the 20MB file, and 5 seconds to draw it.  Internal RAM is no problem - we
have 32MB and can easily expand to 96MB.  We could rewrite the C++
application to take the file and put it into RAM and then access it from
RAM, except that several dozen procedures access this file so it wouldn't
be a trivial effort.

What could be a trivial effort though is using a RAM-DISK.  I'm familiar
with RAM-DISK which I have on my PC.  If I could do the same on UNIX we
could simply create a 20MB ram filesystem and copy the the file there.
The only change to the application would be to change the file path.  

The second less optimal (than the RAM-DISK) would be to set up a
SMART-CACHE (again I have one on my PC) for the file system that has the
20MB file - I would think that UNIX does some internal caching itself, but
I'm not sure how big a cache area it uses.  If it does do internal
caching, is there a way to adjust the caching size to above 20MB?  The
only reason I think this would be less optimal than a RAM-DISK is because
we have a bunch of other stuff running on which the performance isn't
critical which might "clog" up the cache.

Thanks in advance for any replies.  If anyone is interested I can
summarize responses and send via e-mail - let me know.

Thanks,

Tom Magg, attbl!hou2d!tsm, (908)-615-4627, AT&T HR 2H-096, Middletown, NJ 07748