4

ファイル ハッシュ アルゴリズムを最適化して、可能な限りパフォーマンスを低下させようと、かなりの時間を費やしました。

以前の SO スレッドを参照してください。

ファイル ハッシュのパフォーマンスと最適化を取得する

FileChannel ByteBuffer とハッシュ ファイル

適切なバッファ サイズの決定

Java NIOネイティブのパフォーマンスを向上させるために (JVM にバッファを持ち込むのではなく、システム内にバッファを保持することによって)使用することが何度か推奨されました。ただし、私のNIOコードは、ベンチマークでかなり遅く実行されます(結果を歪める可能性のあるOS /ドライブの「魔法」を無効にするために、各アルゴリズムで同じファイルを何度もハッシュします。

私は今、同じことをする2つの方法を持っています:

This one runs faster almost every time:

/**
 * Gets Hash of file.
 * 
 * @param file String path + filename of file to get hash.
 * @param hashAlgo Hash algorithm to use. <br/>
 *     Supported algorithms are: <br/>
 *     MD2, MD5 <br/>
 *     SHA-1 <br/>
 *     SHA-256, SHA-384, SHA-512
 * @param BUFFER Buffer size in bytes. Recommended to stay in<br/>
 *          multiples of 2 such as 1024, 2048, <br/>
 *          4096, 8192, 16384, 32768, 65536, etc.
 * @return String value of hash. (Variable length dependent on hash algorithm used)
 * @throws IOException If file is invalid.
 * @throws HashTypeException If no supported or valid hash algorithm was found.
 */
public String getHash(String file, String hashAlgo, int BUFFER) throws IOException, HasherException {
    StringBuffer hexString = null;
    try {
        MessageDigest md = MessageDigest.getInstance(validateHashType(hashAlgo));
        FileInputStream fis = new FileInputStream(file);

        byte[] dataBytes = new byte[BUFFER];

        int nread = 0;
        while ((nread = fis.read(dataBytes)) != -1) {
            md.update(dataBytes, 0, nread);
        }
        fis.close();
        byte[] mdbytes = md.digest();

        hexString = new StringBuffer();
        for (int i = 0; i < mdbytes.length; i++) {
            hexString.append(Integer.toHexString((0xFF & mdbytes[i])));
        }

        return hexString.toString();

    } catch (NoSuchAlgorithmException | HasherException e) {
        throw new HasherException("Unsuppored Hash Algorithm.", e);
    }
}

My Java NIO method that runs considerably slower most of the time:

/**
 * Gets Hash of file using java.nio File Channels and ByteBuffer 
 * <br/>for native system calls where possible. This may improve <br/>
 * performance in some circumstances.
 * 
 * @param fileStr String path + filename of file to get hash.
 * @param hashAlgo Hash algorithm to use. <br/>
 *     Supported algorithms are: <br/>
 *     MD2, MD5 <br/>
 *     SHA-1 <br/>
 *     SHA-256, SHA-384, SHA-512
 * @param BUFFER Buffer size in bytes. Recommended to stay in<br/>
 *          multiples of 2 such as 1024, 2048, <br/>
 *          4096, 8192, 16384, 32768, 65536, etc.
 * @return String value of hash. (Variable length dependent on hash algorithm used)
 * @throws IOException If file is invalid.
 * @throws HashTypeException If no supported or valid hash algorithm was found.
 */
public String getHashNIO(String fileStr, String hashAlgo, int BUFFER) throws IOException, HasherException {

    File file = new File(fileStr);

    MessageDigest md = null;
    FileInputStream fis = null;
    FileChannel fc = null;
    ByteBuffer bbf = null;
    StringBuilder hexString = null;

    try {
        md = MessageDigest.getInstance(hashAlgo);
        fis = new FileInputStream(file);
        fc = fis.getChannel();
        bbf = ByteBuffer.allocateDirect(BUFFER); // allocation in bytes - 1024, 2048, 4096, 8192

        int b;

        b = fc.read(bbf);

        while ((b != -1) && (b != 0)) {
            bbf.flip();

            byte[] bytes = new byte[b];
            bbf.get(bytes);

            md.update(bytes, 0, b);

            bbf.clear();
            b = fc.read(bbf);
        }

        fis.close();

        byte[] mdbytes = md.digest();

        hexString = new StringBuilder();

        for (int i = 0; i < mdbytes.length; i++) {
            hexString.append(Integer.toHexString((0xFF & mdbytes[i])));
        }

        return hexString.toString();

    } catch (NoSuchAlgorithmException e) {
        throw new HasherException("Unsupported Hash Algorithm.", e);
    }
}

私の考えでは、Java NIOネイティブ システム コールなどを使用して、システム内および JVM の外で処理とストレージ (バッファ) を保持しようとする試みです。これにより、(理論的には) プログラムが JVM とシステム。理論的には、これはより高速になるはずです...しかし、おそらく私MessageDigestはJVMにバッファを強制的に取り込み、ネイティブバッファ/システムコールがもたらすパフォーマンスの向上を無効にしますか? 私はこの論理で正しいですか、それとも間違っていますか?

Please help me understand why Java NIO is not better in this scenario.

4

1 に答える 1

6

おそらくあなたのNIOアプローチをより良くする2つのこと:

  1. データをヒープ メモリに読み込む代わりに、メモリ マップト ファイルを使用してみてください。
  2. 配列の代わりに を使用してByteBuffer、データをダイジェストに渡します。byte[]

1 つ目はファイル キャッシュとアプリケーション ヒープの間でデータをコピーすることを避ける必要があり、2 つ目はバッファーとバイト配列の間でデータをコピーすることを避ける必要があります。これらの最適化がなければ、ナイーブな非 NIO アプローチよりも多くのコピーが発生する可能性があります。

于 2013-05-01T18:41:24.050 に答える