Perl and a Ramdisk

I am working on a chat program and am thinking of using a ramdisk to
hold the chat data. Is there anything special I should know about
accessing ramdisk from perl or is it just another disk to perl? On my
development machine I don't have a ramdisk, so I will be using the HD
for storing while debuging, but on the machine it will run on there is
one, and it would be nice if I could just have a variable holding the
destination and only have to change that instead of changing any
routines that did any file i/o.

Bill H

Re: Perl and a Ramdisk

On Nov 30, 12:46 pm, Bill H wrote:
> I am working on a chat program and am thinking of using a ramdisk to
> hold the chat data. Is there anything special I should know about
> accessing ramdisk from perl or is it just another disk to perl? On my
> development machine I don't have a ramdisk, so I will be using the HD
> for storing while debuging, but on the machine it will run on there is
> one, and it would be nice if I could just have a variable holding the
> destination and only have to change that instead of changing any
> routines that did any file i/o.
>
> Bill H

"Premature optimization is the root of all evil."
-- C. A. R. Hoare

Your plan is good right up to the part where you actually
switch over to using the ramdisk. Every modern OS already
has excellent code to do secure and reliable caching of disk
data. I would see if the disk access is actually a problem
before changing, which should be just the filename that you
open or a symbolic link.

If you do create a ramdisk, you will need to create a
filesystem in it, unless you plan on using the raw disk.
You will also have to preload it and worry about saving
it on shutdown if it will contain any permanent data.
--S

Re: Perl and a Ramdisk

On Nov 30, 1:12 pm, smallpond wrote:
> On Nov 30, 12:46 pm, Bill H wrote:
>
> > I am working on a chat program and am thinking of using a ramdisk to
> > hold the chat data. Is there anything special I should know about
> > accessing ramdisk from perl or is it just another disk to perl? On my
> > development machine I don't have a ramdisk, so I will be using the HD
> > for storing while debuging, but on the machine it will run on there is
> > one, and it would be nice if I could just have a variable holding the
> > destination and only have to change that instead of changing any
> > routines that did any file i/o.
>
> > Bill H
>
> "Premature optimization is the root of all evil."
> -- C. A. R. Hoare
>
> Your plan is good right up to the part where you actually
> switch over to using the ramdisk. Every modern OS already
> has excellent code to do secure and reliable caching of disk
> data. I would see if the disk access is actually a problem
> before changing, which should be just the filename that you
> open or a symbolic link.
>
> If you do create a ramdisk, you will need to create a
> filesystem in it, unless you plan on using the raw disk.
> You will also have to preload it and worry about saving
> it on shutdown if it will contain any permanent data.
> --S

I am not concerned about loosing the data with shutdown, since it is
chat the data is transient, only need what someone types for a few
seconds to echo it to the other chatters. I am more concerned with
speed and less disk accesses. I figure it will be a whole lot faster
open a file, reading, writing, closing files in a ramdisk than in on a
HD.

Bill H

Re: Perl and a Ramdisk

"Bill H" wrote in message
news:e3791e7a-4d6d-4d98-9a14-3c2acdbb23fd@g30g2000hsb.google groups.com...
> On Nov 30, 1:12 pm, smallpond wrote:
>> On Nov 30, 12:46 pm, Bill H wrote:
>>
>> > I am working on a chat program and am thinking of using a ramdisk to
>> > hold the chat data. Is there anything special I should know about
>> > accessing ramdisk from perl or is it just another disk to perl? On my
>> > development machine I don't have a ramdisk, so I will be using the HD
>> > for storing while debuging, but on the machine it will run on there is
>> > one, and it would be nice if I could just have a variable holding the
>> > destination and only have to change that instead of changing any
>> > routines that did any file i/o.
>>
>> > Bill H
>>
>> "Premature optimization is the root of all evil."
>> -- C. A. R. Hoare
>>
>> Your plan is good right up to the part where you actually
>> switch over to using the ramdisk. Every modern OS already
>> has excellent code to do secure and reliable caching of disk
>> data. I would see if the disk access is actually a problem
>> before changing, which should be just the filename that you
>> open or a symbolic link.
>>
>> If you do create a ramdisk, you will need to create a
>> filesystem in it, unless you plan on using the raw disk.
>> You will also have to preload it and worry about saving
>> it on shutdown if it will contain any permanent data.
>> --S
>
> I am not concerned about loosing the data with shutdown, since it is
> chat the data is transient, only need what someone types for a few
> seconds to echo it to the other chatters. I am more concerned with
> speed and less disk accesses. I figure it will be a whole lot faster
> open a file, reading, writing, closing files in a ramdisk than in on a
> HD.
>
> Bill H

I agree, before using a RAMDISK, why not see if using a files on a disk is a
problem? You have created a solution in search of a problem and definitely
putting the cart before the horse. Creating, opening, reading and writing
small files on a RAMDISK is not going to be that much faster than using a
real disk because the amount of data you are reading and writing is small.
Any modern OS is going to cache the data anyway, so in effect you are
already reading and writing to a RAMDISK. If your program does run slow,
using a RAMDISK will not increase performance dramatically because every
process will need to open, read and then close the file. A better solution
would be to use shared memory, which is very efficient, and much faster than
using files to store temporary data needed by multiple processes. There are
several CPAN modules that implement shared memory.

Re: Perl and a Ramdisk

Quoth "Thrill5" :
>
> I agree, before using a RAMDISK, why not see if using a files on a disk is a
> problem? You have created a solution in search of a problem and definitely
> putting the cart before the horse. Creating, opening, reading and writing
> small files on a RAMDISK is not going to be that much faster than using a
> real disk because the amount of data you are reading and writing is small.
> Any modern OS is going to cache the data anyway, so in effect you are
> already reading and writing to a RAMDISK.

Since we are talking about files that change often, every byte written
will have to get flushed to disk at some point. If there is a real disk
involved that means lots of IO, however clever the kernel caching is.

> If your program does run slow, using a RAMDISK will not increase
> performance dramatically because every process will need to open, read
> and then close the file. A better solution would be to use shared
> memory, which is very efficient, and much faster than using files to
> store temporary data needed by multiple processes. There are several
> CPAN modules that implement shared memory.

At least Linux implements both SysV and POSIX shared memory as mmaped
files from a ramdisk. (The ramdisk used for SysV shm is private to the
kernel and doesn't need mounting in userspace, but it is effectively a
mount of tmpfs.)

Ben

Re: Perl and a Ramdisk

On Sat, 01 Dec 2007 23:43:30 +0000, Ben Morrow wrote:

> Quoth "Thrill5" :
>>
>> I agree, before using a RAMDISK, why not see if using a files on a disk
>> is a problem? You have created a solution in search of a problem and
>> definitely putting the cart before the horse. Creating, opening,
>> reading and writing small files on a RAMDISK is not going to be that
>> much faster than using a real disk because the amount of data you are
>> reading and writing is small. Any modern OS is going to cache the data
>> anyway, so in effect you are already reading and writing to a RAMDISK.
>
> Since we are talking about files that change often, every byte written
> will have to get flushed to disk at some point. If there is a real disk
> involved that means lots of IO, however clever the kernel caching is.

Try it. Yes, a ramdisk may be faster, but by how much? Modern OSses are
so intelligent in handling disk I/O I doubt you'll see any difference in
practice.

And yes, I'm talking experience here. Under MSDOS, yes, a well placed
ramdisk made all the difference. Switching to NT and Linux anything I
assigned to a ramdisk became unavailable to the system for diskcaching,
making overall performance a lot worse. But given enough memory disk
caching is so efficient a ramdisk is not noticeably more efficient than a
temporary file on disk.

Also, I've seen a lot of big iron. I've managed a web server and ftp
server that on a certain day every year are the most visited Internet
servers in the Netherlands. Not the same use case but we managed a lot of
servers there. Not one used a ramdisk, just because there was no
performance to be gained. Just let the OS sort it out, monitor it, and
when it runs out of memory, add more memory.

By all means try it. I'll be very surprised if a ramdisk gives you any
real performance benefits.

HTH,
M4

Re: Perl and a Ramdisk

Bill H wrote:
>
> I am not concerned about loosing the data with shutdown, since it is
> chat the data is transient, only need what someone types for a few
> seconds to echo it to the other chatters. I am more concerned with
> speed and less disk accesses. I figure it will be a whole lot faster
> open a file, reading, writing, closing files in a ramdisk than in on a
> HD.

As has been pointed out, any decent OS will
perform cacheing of HD data, in (well...) RAM.

BugBear