0

PDFファイルを編集するJavaアプリケーションに取り組んでいます。さらに、ghostscript を使用したシェル スクリプトを使用して Pdf のイメージを作成し、その後イメージを Java アプリケーションでバッファ イメージとして読み込みます。もちろん、イメージの作成には時間がかかります。イメージをハードディスクに保存することを避けることはできますか? 代わりに、RAM にのみ存在する仮想の場所を使用したいと考えています。これを検索しようとしましたが、探しているキーワードがわかりません。

4

2 に答える 2

1

イメージを (ディスク ファイルではなく) に出力するように Ghostscript を作成できますstdout。次に、から読み取る別のプログラム (または Java アプリケーション) を作成できますstdin。

その結果、パイプを介して両方のアプリケーションを簡単に接続できます。パイプは確かに「RAM にのみ存在する仮想的な場所」であり、このために追加の仮想ファイル システムを作成する必要はありません。

Ghostscript 構文 (Linux、Unix、MacOSX):

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

これにより、出力ファイルがディスクに書き込まれることは確実に回避されます...

ただし、あなたの主な懸念は、実際に出力をディスクに書き込む (およびディスクから再度読み取る) と、貴重な処理時間がかかりすぎることです。

Ghostscript の実際の処理は、ディスクへの結果の書き込みよりもはるかに遅い場合があります。この場合、ディスク I/O を回避した場合、純利益はそれほど大きくありません。

幸いなことに、両方のアプローチの違いを簡単に測定してベンチマークすることができます ((1) 最初に Ghostscript を使用してファイルをディスクに書き込み、次に 2 番目のアプリケーションを使用してディスクからファイルを再度読み取る、(2) ファイルをパイプに書き込み、パイプから直接読み取る)。 2 番目のアプリケーションで) 典型的な PDF 入力の一部:

まず、「ディスクに書き込み、ディスクから再度読み取る」アプローチ:

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

サンプル PDF の結果:

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

次に、「ディスク I/O オーバーヘッドを回避して、パイプラインを介して両方のプログラムを接続する」アプローチ:

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

同じサンプル PDF の結果:

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

3 番目に、2 番目のプログラムがディスクからファイルを読み取って処理するのに必要な時間を測定します。

identify 1.tiff

この例での私の結果:

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

もちろん、サンプルの結果は非常に異なる可能性があります。しかし、そのような測定を行う (そして何度も繰り返す) ことは、あなたのケースで「ディスク I/O を回避する」ことが価値のあるパフォーマンスの向上につながるかどうか、またどれだけの向上が期待できるかを判断する唯一の方法です。

于 2012-06-19T16:57:43.843 に答える
0

Apache Commons VFSを試してみてください。仮想ファイルシステム API といくつかの便利な実装、特にRAMをもたらします。

于 2012-06-19T12:20:06.200 に答える