Question

Im working on a Java Application that edits Pdf files. Furthermore a shell script with ghostscript is used to make an image of the Pdf and after that the image is read in the Java Application as a Buffered Image. Of course the creating of the image takes some time. It is possible to avoid to save the Image on hard disk? Instead I want to use a virtual place that exist only in the RAM. I tried to search for this, but Im not sure for what keyword Im looking for.

Answer 1

You can make Ghostscript to output the image (not to a disk file, but) to stdout. Then you could make another program (or your Java application) to read from stdin.

As a result it would be easy to connect both applications through a pipe. A pipe is surely a ‘virtual place that only exists in RAM’, and you do not need to create an extra virtual file system for this.

Ghostscript syntax (Linux, Unix, MacOSX):

gs \
  -q \
  -dBATCH \
  -dNOPAUSE \
  -sOutputFile=%stdout \
  -sDEVICE=tiffg4 \
  -r600 \
  -dLastPage=1 \
   input.pdf \
| \
identify - 

This will surely avoid writing the output file to disk…

However, your main concern seems to be that actual writing to disk of the output (and again reading from disk) would cost you too much valuable processing time.

It could be the case that Ghostscript’s actual processing is much slower than writing of the results to disk. In this case your net win wouldn’t be that great if you avoided the disk I/O.

The good news is that you can easily measure and benchmark the difference between both approaches ((1) write file to disk with Ghostscript first and then read file from disk again with 2nd application; (2) write file to pipe and read directly from pipe with 2nd application) with some of your typical PDF input:

First, the ‘write to disk and read again from disk’ approach:

time \
(gs \
  -q \
  -dBATCH \
  -dNOPAUSE \
  -sOutputFile=1.tiff \
  -sDEVICE=tiffg4 \
  -r600 \
  -dLastPage=1 \
   input.pdf \
&& \
identify 1.tiff) 

My result for a sample PDF:

real  0m1.231s
user  0m1.188s
sys   0m0.024s

Second, the ‘connect both programs through a pipeline, avoiding disk I/O overhead’ approach:

time \
gs \
  -q \
  -dBATCH \
  -dNOPAUSE \
  -sOutputFile=%stdout \
  -sDEVICE=tiffg4 \
  -r600 \
  -dLastPage=1 \
   input.pdf \
| \
identify - 

My result for the same sample PDF:

real  0m1.459s
user  0m1.422s
sys   0m0.036s

Third, measure the time your 2nd program needs to read and process file from disk:

identify 1.tiff

My result in this example:

real  0m0.023s
user  0m0.011s
sys   0m0.006s

Of course, your results for your samples could be very, very different. But doing (and repeating a number of times) such measurements is the only way to determine if ‘avoiding disk I/O’ in your case would lead to a performance gain that is worth while, and also how much gain can be expected.