creating a ram drive in csharp

  • Thread starter Thread starter krach.aran
  • Start date Start date
K

krach.aran

At the moment i am implementing a ghostscript application in c#.

The Dll functions that i can import via dllimport all write to disk
directly.
As i want base64 encode the files, i don't want the slow disk access,
but do all functions in memory.

Could someone tell me if there is a way in which i can create a ram
drive, which i can write to ??

At the moment i am gooling my butt off but can't find anything

TIA

Otto
 
Hello ebbe

I use the following dll import from gsdll32.dll

[DllImport("gsdll32.dll", EntryPoint="gsapi_init_with_args")]
private static extern int gsapi_init_with_args (IntPtr instance, int
argc, IntPtr argv);

As you can see the dll uses a argcounter and argvalues. The values are
filled with the following values:

args[0]="-dNOPAUSE";
args[1]="-dBATCH";
args[2]="-dSAFER";
args[3]="-sDEVICE=pdfwrite";
args[4]="-sOutputFile="+outputFile;
args[5]=inputFile;

both inputfile and outputfile contain a path or unc. there is no
functionality for using any stream type's.
can the memory mapped files be reached by a path.

or are memory mapped files just kind of pointer that i have to pass
from one application to another ???
 
At the moment i am implementing a ghostscript application in c#.

The Dll functions that i can import via dllimport all write to disk
directly.
As i want base64 encode the files, i don't want the slow disk access,
but do all functions in memory.

Could someone tell me if there is a way in which i can create a ram
drive, which i can write to ??

At the moment i am gooling my butt off but can't find anything

TIA

Otto
Click to expand...
Do the DLL functions write to a file, or to a file stream? If to a
file stream then you might get the effect that you want by using a
memory stream.

DLL -> memoryStream -> Base64 -> disk

rossum
 
or are memory mapped files just kind of pointer that i have to pass
from one application to another ???
Click to expand...

Memory mapped files are loaded into memory but otherwise behave as ordinary
files. Thus you get the speed advantage of having the file in memory without
bothering the OS - and the interface is exactly the same as if you accessed
the file on disk. You may find some more info here:

http://www.catch22.net/tuts/bigmem01.asp

Ebbe
 
Hello ebbe

I use the following dll import from gsdll32.dll

[DllImport("gsdll32.dll", EntryPoint="gsapi_init_with_args")]
private static extern int gsapi_init_with_args (IntPtr instance, int
argc, IntPtr argv);

As you can see the dll uses a argcounter and argvalues. The values are
filled with the following values:

args[0]="-dNOPAUSE";
args[1]="-dBATCH";
args[2]="-dSAFER";
args[3]="-sDEVICE=pdfwrite";
args[4]="-sOutputFile="+outputFile;
args[5]=inputFile;

both inputfile and outputfile contain a path or unc. there is no
functionality for using any stream type's.
can the memory mapped files be reached by a path.
Click to expand...

No, they can't.
But this aside why do you want to re-invent the wheel and implement a RAM disk in C#, there
are plenty of RAM disk implementations available in the public domain.

Willy.
 
Okey, here is a complete drill-down of my scenario :
- Enviroment is a windows 2003 server wunning a windows service.
- Due to company policy i am unable to install any software on the
server.
- I'm looking for a "Microsoft" solution without the use of third party
tools. Again because of company rules.

My windows service works as follows :
- it listens to a websphere MessageQueue from wich it receives a soap
message
- the soap contains base64 Postscript data
- file has to beconverted (this is my tricky part)
- file has to be re-encoded as a base64 string, and sent back as a soap
message

Due to requirements of the conversion only 1 package will do namely
ghostscript (which is currently going through a package acceptation by
the company ict managment)
ghostscript accepts only file paths as parameters. all disk io is done
by the dll that is called.
I want to avoid disk usage as much as possible to gain in speed.


hopefully this gives a better view of my problem (so not only technical
but also policy is in my way).
 
Okey, here is a complete drill-down of my scenario :
- Enviroment is a windows 2003 server wunning a windows service.
- Due to company policy i am unable to install any software on the
server.
- I'm looking for a "Microsoft" solution without the use of third party
tools. Again because of company rules.
Click to expand...

A RAM disk consist of a device driver. So, your only option (due to policy) is to develop
such a driver yourself using the WDK (Windows Driver Kit). Wonder whether the company rules
will allow you to install such device driver though.
Not also the only sofisticated drivers will outperform the OS cache manager, most RAM disk
drivers available perform worse than a modern Hard Disk subsystem.

My windows service works as follows :
- it listens to a websphere MessageQueue from wich it receives a soap
message
- the soap contains base64 Postscript data
- file has to beconverted (this is my tricky part)
- file has to be re-encoded as a base64 string, and sent back as a soap
message

Due to requirements of the conversion only 1 package will do namely
ghostscript (which is currently going through a package acceptation by
the company ict managment)
ghostscript accepts only file paths as parameters. all disk io is done
by the dll that is called.
I want to avoid disk usage as much as possible to gain in speed.
Click to expand...

I'm not sure whether you will gain anything when using a RAM disk, as said above modern disk
subsystems are quite performant. Anyway, the only way to find out wheter a RAM disk would be
of any help is *measure*, however, as your environment is constrained by company policies, I
don't see how you will be able to accomplish this.
Note also that I doubt you will gain anything at all using A RAM disk, after all, the
slowest link is the network (10-100? times slower than a disk).


Willy.
 
Willy Denoyette said:
A RAM disk consist of a device driver. So, your only option (due to policy) is to develop
such a driver yourself using the WDK (Windows Driver Kit). Wonder whether the company
rules will allow you to install such device driver though.
Not also the only sofisticated drivers will outperform the OS cache manager, most RAM disk
Click to expand...

Sorry above should read:
Note, that only sophisticated ...

Willy.
 
Thnx for the response willy,

I think i'm just sticking to writing to disk and doing some performance
test there.
Tomorrow i'm doing a stress test and will await the results of that.
If disk performance is low due to huge file size's, i will then fall
back to another scenario.

Maybe an infrastructure solution raid / cache / clustering will provide
the required QOS i want.

I would like to thank everyone in the thread for their comment's.

If i ever find a good solution i will post it here again.
 
Thnx for the response willy,

I think i'm just sticking to writing to disk and doing some performance
test there.
Tomorrow i'm doing a stress test and will await the results of that.
If disk performance is low due to huge file size's, i will then fall
back to another scenario.
Click to expand...
Don't know what you call huge files, but beware that your RAM disk must be at least the size
of your largest file, and this RAM space can't be used for anything else in the system,
there are far better way's to use your available RAM, really.

Maybe an infrastructure solution raid / cache / clustering will provide
the required QOS i want.
Click to expand...
I'm don't think that Ghostscript would be able to saturate a single modern disk subsystem.
Anyway, a raid0 configuration with a couple of SATA2 drives will easily outperform a RAM
disk,

Willy.
 
"most RAM disk drivers available perform worse than a modern Hard Disk subsystem"

Is that true for mutliple random access to a large file? I would have thought that the seek time of
a hard disk subsystem would seriously slow things down if the file size is considerably larger than
the hard disk cache size. By using a RAM disk, the seek time should be much faster.



Okey, here is a complete drill-down of my scenario :
- Enviroment is a windows 2003 server wunning a windows service.
- Due to company policy i am unable to install any software on the
server.
- I'm looking for a "Microsoft" solution without the use of third party
tools. Again because of company rules.
Click to expand...

A RAM disk consist of a device driver. So, your only option (due to policy) is to develop
such a driver yourself using the WDK (Windows Driver Kit). Wonder whether the company rules
will allow you to install such device driver though.
Not also the only sofisticated drivers will outperform the OS cache manager, most RAM disk
drivers available perform worse than a modern Hard Disk subsystem.

My windows service works as follows :
- it listens to a websphere MessageQueue from wich it receives a soap
message
- the soap contains base64 Postscript data
- file has to beconverted (this is my tricky part)
- file has to be re-encoded as a base64 string, and sent back as a soap
message

Due to requirements of the conversion only 1 package will do namely
ghostscript (which is currently going through a package acceptation by
the company ict managment)
ghostscript accepts only file paths as parameters. all disk io is done
by the dll that is called.
I want to avoid disk usage as much as possible to gain in speed.
Click to expand...

I'm not sure whether you will gain anything when using a RAM disk, as said above modern disk
subsystems are quite performant. Anyway, the only way to find out wheter a RAM disk would be
of any help is *measure*, however, as your environment is constrained by company policies, I
don't see how you will be able to accomplish this.
Note also that I doubt you will gain anything at all using A RAM disk, after all, the
slowest link is the network (10-100? times slower than a disk).


Willy.
 
Jay said:
"most RAM disk drivers available perform worse than a modern Hard Disk subsystem"

Is that true for mutliple random access to a large file? I would have thought that the
seek time of
a hard disk subsystem would seriously slow things down if the file size is considerably
larger than
the hard disk cache size. By using a RAM disk, the seek time should be much faster.
Click to expand...

True, but the OP is not talking about a desktop but about a server system, modern HD
subsystems (with entry level RAID controllers) with 256MB and more read/write cache are
common. Also on this kind of servers you can't afford to waste say +500MB of precious RAM
for a RAM drive, note that this memory is taken from systems memory normally used as FS
cache, so here you start competing with the systems IO subsystem, probably reducing the
overall system performnce.

Willy.
 
Good points Willy, thanks for your comments.


Jay said:
"most RAM disk drivers available perform worse than a modern Hard Disk subsystem"

Is that true for mutliple random access to a large file? I would have thought that the
seek time of
a hard disk subsystem would seriously slow things down if the file size is considerably
larger than
the hard disk cache size. By using a RAM disk, the seek time should be much faster.
Click to expand...

True, but the OP is not talking about a desktop but about a server system, modern HD
subsystems (with entry level RAID controllers) with 256MB and more read/write cache are
common. Also on this kind of servers you can't afford to waste say +500MB of precious RAM
for a RAM drive, note that this memory is taken from systems memory normally used as FS
cache, so here you start competing with the systems IO subsystem, probably reducing the
overall system performnce.

Willy.
 
Note about Ghostscript (which started this thread, and for posterity). On Windows Vista, the Ghostscript API can be made to output to named pipes, eliminating the need to create temporary files. This may or may not impact performance in a positive way, as apparent disk performance could match in-memory file performance. However, it does eliminate the need to delete the temporary files after generation. If using the Ghostscript executable directly, one also could of course interact with the program by attaching to STDIN / STDOUT.
 
Back
Top