資訊專欄INFORMATION COLUMN
摘要：當(dāng)主機(jī)正在從某個(gè)輸入流源源不斷地讀取文件時(shí)，校驗(yàn)碼的計(jì)算是實(shí)時(shí)的，每次校驗(yàn)操作都只對(duì)文件的一部分進(jìn)行處理。在計(jì)算校驗(yàn)碼時(shí)，請(qǐng)至少使用的分區(qū)大小，否則調(diào)用會(huì)造成不可忽略的時(shí)間消耗。
原文：java.util.zip.CRC32 and java.util.zip.Adler32 performance
作者：Mikhail Vorontsov
校驗(yàn)碼是把任意長度的字節(jié)內(nèi)容輸入通過特定算法變換為一個(gè)長度較短的字節(jié)數(shù)組（在CRC32和Adler32中變換為整數(shù)（Integer））。校驗(yàn)碼最主要的一個(gè)特點(diǎn)是，即使輸入內(nèi)容發(fā)生了很小的變化，輸出內(nèi)容也會(huì)有極為明顯的差別。校驗(yàn)算法通常在以下兩種場(chǎng)景中使用：
當(dāng)主機(jī)已經(jīng)分別接收到一個(gè)完整文件和其對(duì)應(yīng)的校驗(yàn)碼時(shí)，我們要計(jì)算出整個(gè)文件的校驗(yàn)碼，與接收到的校驗(yàn)碼進(jìn)行對(duì)比，來確認(rèn)文件在傳輸?shù)倪^程中沒有被篡改。
當(dāng)主機(jī)正在從某個(gè)輸入流源源不斷地讀取文件時(shí)，校驗(yàn)碼的計(jì)算是實(shí)時(shí)的，每次校驗(yàn)操作都只對(duì)文件的一部分進(jìn)行處理。當(dāng)某些原因?qū)е轮鳈C(jī)與輸入設(shè)備的連接斷開，主機(jī)嘗試重新傳輸時(shí)，我們會(huì)使用最后一次計(jì)算得到的校驗(yàn)碼和讀取到的文件位置與當(dāng)前重傳的數(shù)據(jù)內(nèi)容進(jìn)行比較，以免對(duì)前面已經(jīng)傳輸過的數(shù)據(jù)進(jìn)行重新處理，從而使得傳輸可以從當(dāng)前位置繼續(xù)進(jìn)行。
在標(biāo)準(zhǔn)JDK中，最常使用的校驗(yàn)算法是java.util.zip.CRC32。許多開發(fā)者認(rèn)為這是Java唯一的標(biāo)準(zhǔn)校驗(yàn)算法實(shí)現(xiàn)（其中也有人會(huì)說這是標(biāo)準(zhǔn)的CRC（Cyclic Redundancy Check，循環(huán)冗余校驗(yàn)）實(shí)現(xiàn)）。實(shí)際上，Java中還有另一種校驗(yàn)算法叫java.util.zip.Adler32，這兩種算法都實(shí)現(xiàn)了同一個(gè)接口：java.util.zip.Checksum。
這兩種校驗(yàn)算法是有區(qū)別的，Adler32比CRC32稍微弱一些，不過如果當(dāng)需要校驗(yàn)的內(nèi)容長達(dá)幾千字節(jié)甚至更多時(shí)，你可以忽略校驗(yàn)質(zhì)量上的差異。更重要的是，Adler32的計(jì)算速度比CRC32快。下面的列表對(duì)這兩種校驗(yàn)算法的處理速度進(jìn)行了比較，處理的內(nèi)容是一個(gè)500MB的存檔文件（文件已經(jīng)預(yù)先讀取到內(nèi)存中）
500MB數(shù)據(jù)容校驗(yàn)速度對(duì)比
| Adler32，一次性處理 | CRC32，一次性處理 | Adler32，每次處理區(qū)塊大小10 bytes | CRC32，每次處理區(qū)塊大小10 bytes | Adler32，每次處理區(qū)塊大小1000 bytes | CRC32，每次處理區(qū)塊大小1000 bytes | |
|---|---|---|---|---|---|---|
| Java 6 | 0.233 s | 1.526 s | 3.585 s | 4.119 s | 0.253 s | 1.545 s |
| Java 7 | 0.227 s | 0.666 s | 3.684 s | 3.691 s | 0.267 s | 0.699 s |
如你所見，在Java 6中，當(dāng)單次處理的區(qū)塊足夠大時(shí)，Adler32的速度是CRC32的5~6倍；而在Java 7中明確地對(duì)CRC32進(jìn)行了性能優(yōu)化，Adler32的速度只比CRC32快了2~3倍。使用小容量的區(qū)塊進(jìn)行處理時(shí)，JNI調(diào)用的成本是影響速度的最大因素。
有人可能覺得0.3s和1.5s的時(shí)間差異對(duì)于500MB的內(nèi)容來說沒有什么值得關(guān)注的地方，這并不完全正確。如今硬盤的讀取速度能達(dá)到100M/s，讀取500MB數(shù)據(jù)最多只需要5s，在這樣的情況下，額外的1秒時(shí)間（1.5-0.3 s）就會(huì)造成20%的性能下降。換個(gè)方式說，你可以理解為“我們的系統(tǒng)使用CRC32能達(dá)到500,000條信息/每秒的處理速度，而使用Adler32可以達(dá)到600,000條信息/每秒”。
總結(jié)如果你可以自由選擇校驗(yàn)算法實(shí)現(xiàn)，你可以先嘗試使用Adler32。如果它的校驗(yàn)質(zhì)量對(duì)你來說已經(jīng)足夠了的話，使用它比CRC32要更好。無論在什么情況下，你應(yīng)當(dāng)使用Checksum接口來訪問Adler32/CRC32的邏輯。
在計(jì)算校驗(yàn)碼時(shí)，請(qǐng)至少使用500 bytes的分區(qū)大小，否則JNI調(diào)用會(huì)造成不可忽略的時(shí)間消耗。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/68648.html
摘要：完整版地址我們的想法是創(chuàng)建一個(gè)深度學(xué)習(xí)框架的羅塞塔石碑假設(shè)你很了解某個(gè)深度學(xué)習(xí)框架，你就可以幫助別人使用任何框架。我們的目標(biāo)是創(chuàng)建深度學(xué)習(xí)框架的羅塞塔石碑，使數(shù)據(jù)科學(xué)家能夠在不同框架之間輕松運(yùn)用專業(yè)知識(shí)。 repo 1.0 完整版 GitHub 地址：https://github.com/ilkarman/DeepLearningFrameworks我們的想法是創(chuàng)建一個(gè)深度學(xué)習(xí)框架的羅塞塔石...
摘要：在本文中我將會(huì)介紹應(yīng)用性能優(yōu)化的一般原則。性能優(yōu)化的流程圖摘取自和合著的性能，描述了應(yīng)用性能優(yōu)化的處理流程。例如，對(duì)每臺(tái)服務(wù)器，你面臨著為單個(gè)分配堆內(nèi)存和運(yùn)行個(gè)并為每個(gè)分配堆內(nèi)存的選擇。不過位能使用堆內(nèi)存最大理論值只有。 原文鏈接：http://www.cubrid.org/blog/dev-platform/the-principles-of-java-application-per...
摘要：機(jī)型機(jī)型云主機(jī)根據(jù)應(yīng)用場(chǎng)景將主機(jī)區(qū)分為快杰型通用型高主頻型型總計(jì)種機(jī)型。若希望使用現(xiàn)有鏡像創(chuàng)建快杰型云主機(jī)，請(qǐng)聯(lián)系技術(shù)支持。不同平臺(tái)的云主機(jī)價(jià)格相同。此文檔適合于2019年5月后新上線的新版主機(jī)創(chuàng)建頁，重新定義了大部分機(jī)型的概念，這些新概念被聚合為主機(jī)機(jī)型概念2.0。若您仍然使用舊版本的主機(jī)創(chuàng)建頁，機(jī)型概念請(qǐng)參照主機(jī)概念1.0的文檔機(jī)型與規(guī)格；若您希望了解2.0概念與1.0概念相比發(fā)生了哪些...
摘要：注意年月上線新版主機(jī)創(chuàng)建頁后，主機(jī)機(jī)型概念已升級(jí)到版本。請(qǐng)參照機(jī)型與平臺(tái)機(jī)型與平臺(tái)進(jìn)行選型。以下為版主機(jī)概念的文檔規(guī)格族簡述規(guī)格族簡述云主機(jī)根據(jù)應(yīng)用場(chǎng)景將主機(jī)區(qū)分為標(biāo)準(zhǔn)型高型高主頻型型總計(jì)種規(guī)格族，并支持總計(jì)個(gè)系列的種機(jī)型。注意：2019年5月上線新版主機(jī)創(chuàng)建頁后，主機(jī)機(jī)型概念已升級(jí)到2.0版本。此文檔描述的1.0版本概念將不再沿用。請(qǐng)參照?機(jī)型與CPU平臺(tái)?進(jìn)行選型?？刂婆_(tái)列表展示的機(jī)型也...
閱讀 1974·2021-09-04 16:45
閱讀 764·2019-08-30 15:44
閱讀 905·2019-08-30 13:07
閱讀 468·2019-08-29 16:06
閱讀 1391·2019-08-29 13:43
閱讀 1286·2019-08-26 17:00
閱讀 1533·2019-08-26 13:51
閱讀 2305·2019-08-26 11:48
