那麼久，今天才看到別人1月份就寫出來的Report，D.S.Lite在下載時I/O量的確是個驚人的數據成長，各位可以依照以下轉貼的報告自己嘗試看看，再與SmartGet做比較，我想或許以後大家就會跟我一樣盡量避免使D.S.Lite了。
一、首先, 告訴大家如何觀察一個應用程式對硬碟讀取寫入的次數1.打開工作管理員，點選「選擇欄位」的功能表項目
2.把「I/O寫入次數」和「I/O讀取次數」兩個欄位勾起來後按下確定
3.好了，每個程式所對應的硬碟寫入讀取次數就出現了
二、接著先觀察 DSLite 上傳郵件檔案對硬碟存取的次數1.一打開 DSLite, 大約讀取硬碟 4 萬次(這跟資料筆數有關, 不多全部只有 1000 筆左右)
2.如何用 DSLite 寄信就不多做說明, 我們選擇一個 9 MB 左右的檔案, 並按下開始
3.出現這個窗口
4.這時 DSLite 要預先把整封信件編碼好, 再開始寄送, 這個過程讀取硬碟 16 萬次(每 9 MB)
三、再來看 DSLite 下載郵件又是如何存取硬碟的(如果因為演示圖片太大被縮小了請點一下圖片, 它就會還原比例)
1.重新打開 DSLite, 讀取次數如之前 4 萬次, 寫入 4 萬多次不知為何,猜測是建立 .bak 檔的時候寫的
2.選擇下載一個 20 MB 的信件檔。下載到 89% 的時候, 寫入次數到達了 5 萬多次,也就是每下載 10 多 MB的郵空檔, 就要寫入約 1 萬次
3.下載到 99% 的時候，就是大家所知道會停頓很久 CPU 飆高之時,此時 DSLite 在做什麼呢? 原來它剛剛只是把信件下載到了 Temp 資料夾, 此時要把信件裡的附件檔(因為附件一般經過 BASE64 的編碼)解碼到目標資料夾。可是同樣地它沒有做緩衝區, 每不到 100 Byte解碼就直接輸出, 此時硬碟寫入次數會非常之快地的飆高。下面這張圖解信解到一半時已達到 269 萬次:
4.下面這張圖出現 Stream Write Error 的錯誤, 因為我不敢讓它寫到硬碟, 所以存放在 Ramdisk, 而 R 槽只剩下 9 MB 的容量, 所以顯示出這個寫不進去了的錯誤. 也就是說, 解信每解 9 MB就要寫入硬碟近 500萬次, 有人會說硬碟本來就是消耗品, 這是合理的開銷, 可是, 它可以去比較其它的下載軟體, 是不是會這麼誇張, 就連 BT 也比不上. 明顯這是一個軟體設計失當, 對硬碟的傷害無以復加
報告轉貼自d4lyric@FDzone，圖片重新上傳 
0