2009-11-03 65 views

回答

5

如果執行二進制unzip,你的進程會fork/exec和

  1. 實例化一個新的進程
  2. 佔用更多的內存(用於衍生進程的持續時間)

你還必須配置正確的路徑到unzip。鑑於這一切,我強烈希望圖書館的方法。

+3

我從來不理解這種想法。 fork/exec是一個非常快速的過程,任何花時間閱讀或編寫shell腳本的人都會意識到這一點。解壓縮二進制本身消耗的內存相對於算法和(特別是)其中的數據成本而言是微不足道的。並且/ usr/bin/unzip默認在每個Linux發行版上發佈,我也相信BSD和Cygwin。 除非你有如下簡單的示例代碼:'open my $ input「,unzip -cp $ ARCHIVE $ FILE |」',我寧願選擇簡單的選項。 – 2009-11-03 17:47:19

+1

雖然我同意上面的*一般*,如果您的服務器負載很重,那麼您的資源消耗將會隨着fork/exec模型的增加而增加。 pid分配,進程間流分配,內存分配(允許寫入時複製)。對於獨立進程,我很滿意fork/exec模型。對於服務器模型,我更願意以最少的資源分配來回避這種模式。 – 2009-11-03 18:05:51

+1

如果你在一個循環中分支,特別是一個熱循環,你絕對會看到性能問題。如果你不在循環中,或者如果你以每秒一次或每幾秒一次的速度分叉,那麼沒問題。另外,使用庫而不是系統的'unzip'命令可能是一個好處;圖書館可能會更新,更少車。 – 2013-04-11 04:47:23

14

按照Archive::Zip documentation你會更好使用Archive::Extract

如果你只是要建議您看看使用存檔提取拉鍊(和/或其他檔案)::提取物相反,因爲它更容易使用,並歸因於存檔特定的功能。

這很有趣,因爲Archive::Extract will try Archive::Zip first and then fall back to the unzip binary if it fails.所以看起來Archive :: Zip似乎是首選。

Archive :: Zip使用Compress::Raw::Zlib這是zlib系統庫的低級接口;所以它不是純粹的Perl實現,這意味着它的性能與unzip相似。換句話說,從性能角度來看,沒有理由在Archive :: Zip之前選擇unzip

+3

如果使用'Archive :: Extract',那麼它也適用於其他壓縮格式。 – 2009-11-03 17:24:54

1

一個問題是內存。我們發現Archive::Tar存在內存泄漏的難題(生產Web服務器崩潰)。因此,儘管整體使用模塊而不是系統調用外部命令是一個好主意(請參閱其他推理的回覆),但您需要確保模塊沒有陷阱。

相關問題