MozTW 討論區 https://forum.moztw.org/ |
|
FB 7631 KB -> 2757KB https://forum.moztw.org/viewtopic.php?f=2&t=1332 |
第 1 頁 (共 1 頁) |
發表人: | 訪客 [ 2003-08-24, 13:47 ] |
文章主題 : | FB 7631 KB -> 2757KB |
FB (英文版 )執行檔大小有 7,631KB這麼大,經過UPX 壓縮後,檔案大小為 2,757KB (參數 --best ,注意大小寫),執行起來一切正常,除了可以大幅縮短載入的時間.... 除此之外 像是常用的FLASHGET 1.4 (1,172 KB -> 462 KB ) UltimateZip (2,850KB -> 834KB ) 載入時間也可以大幅縮短....^_^ =============== 當然 UPX也不是萬能的,有兩種情況UPX就不太適用(雖然檔案縮小了,但是系統記憶抵資源卻耗用的已被數計算) 1.會同時執行數個INSTANCE的應用程式,因為資源不能SHARE。 2.DLL檔,因為檔案是在記憶體裏解壓縮,DLL的PAGE都被標成MODIFIED,如果別的軟體或是另一個INSTANCE呼叫這個DLL,那OS會再配置另一塊記憶體來執行第二份DLL |
發表人: | piaip [ 2003-08-25, 21:48 ] |
文章主題 : | |
打個註解。 我知道 UPX 之類的東西,不過事實上 UPX 是會縮短 disk access 的時間, 但解壓縮的動作本身卻又會花 CPU 的時間。 所以,如果是 cpu 很快而 disk 慢的,用 UPX 不錯; 反之就不能用了。 也因為如此,upx 就留給有需求的人自己去跑, 預設的安裝檔通常不會這樣處理,因為安裝檔本身就有壓縮了。 |
發表人: | 9607 [ 2003-08-27, 00:11 ] |
文章主題 : | |
piaip 寫: 打個註解。
我知道 UPX 之類的東西,不過事實上 UPX 是會縮短 disk access 的時間, 但解壓縮的動作本身卻又會花 CPU 的時間。 所以,如果是 cpu 很快而 disk 慢的,用 UPX 不錯; 反之就不能用了。 也因為如此,upx 就留給有需求的人自己去跑, 預設的安裝檔通常不會這樣處理,因為安裝檔本身就有壓縮了。 1.UPX 在 PENTIUM-133 上可以達到 10MB /SEC的解壓縮速度,也就是說現在動輒1G(就算沒1G,4~500MHZ也夠了)的CPU可以達到每秒解壓100MB以上的速度..換算起來解壓縮只佔了"原本載入時間的"的幾十分之一~幾百分之一... 2.拿FB6.01來舉例,在4KB大小的CLUSTER 狀況下,FB原本要載入1904個CLUSTER...而UPX後只要載入670個CLUSTER..在 1的情況成立下,載入速度可以單純的換算為接近 2.84倍...^^ 3.一般的安裝檔,當然是經過壓縮的,但是在安裝過程中解壓縮後,一些執行檔還是變的很大....和經UPX壓縮有很大的差距.. 4.UPX 不祇是單純的COMPRESS檔案而已,還把一些多餘的資訊加以處理,以達到更大的壓縮比..詳細資料請上UPX網站... 5.若能在製作安裝檔前把執行檔UPX,那製作出來的安裝包 也會體積減少不小喔... |
發表人: | piaip [ 2003-08-27, 02:03 ] |
文章主題 : | |
(1)(2)嗯,Firebird forum 上面有人討論過 upx 壓縮後真正產生的效率影響, 結論是整體考慮起來負面影響較大,所以目前好像沒有人出 upx 後的版本。 (3)解壓縮後當然是會變大,所以空間真的不夠的人是適合用 upx 的, 所以,upx 應該會適合安裝後有需求的人自行使用。 (4)upx 的理論我大概理解,Win32的 executable format 我想我也還算熟, 其實很早前我就有在玩upx了,它 strip 掉的資訊以 reallocation table 為主,而 Mozilla 如果拿掉這個可能會不能跑,Firebird 用 static link 所以很多版本通常一開始就拿掉了... 效果有限。 (5)理論上這是不可能的事。根據壓縮的原理,如果安裝檔壓縮跟多一次 upx 可以產生到「不小」的差距,那代表壓縮的演算法有誤、或還不是最佳的。 當然前提是 upx 沒有減少資訊量。由 (4) 得知,upx 減少的資訊量應該不多。 |
發表人: | 9607-2 [ 2003-09-04, 18:22 ] |
文章主題 : | |
piaip 寫: (1)(2)嗯,Firebird forum 上面有人討論過 upx 壓縮後真正產生的效率影響,
結論是整體考慮起來負面影響較大,所以目前好像沒有人出 upx 後的版本。 (3)解壓縮後當然是會變大,所以空間真的不夠的人是適合用 upx 的, 所以,upx 應該會適合安裝後有需求的人自行使用。 (4)upx 的理論我大概理解,Win32的 executable format 我想我也還算熟, 其實很早前我就有在玩upx了,它 strip 掉的資訊以 reallocation table 為主,而 Mozilla 如果拿掉這個可能會不能跑,Firebird 用 static link 所以很多版本通常一開始就拿掉了... 效果有限。 (5)理論上這是不可能的事。根據壓縮的原理,如果安裝檔壓縮跟多一次 upx 可以產生到「不小」的差距,那代表壓縮的演算法有誤、或還不是最佳的。 當然前提是 upx 沒有減少資訊量。由 (4) 得知,upx 減少的資訊量應該不多。 (1)負面影響.....不知道是哪'方面的負面影響呢 ? WIN2000如果 LARGESYSTEMCACHE=0 的話CACHE 是8MB (XP LARGESYSTEMCACHE預設是0..) 9X系列 VCACHE大過 32MB也沒有助益,所以如果FB執行檔大小從接近8MB縮小到2mb多,cache的運用比較有效益(當然前提事項我這樣FB開開關關的...) (5) 的確是我想錯了.... |
發表人: | piaip [ 2003-09-05, 01:27 ] |
文章主題 : | |
9607-2 寫: (1)負面影響.....不知道是哪'方面的負面影響呢 ?
WIN2000如果 LARGESYSTEMCACHE=0 的話CACHE 是8MB (XP LARGESYSTEMCACHE預設是0..) 9X系列 VCACHE大過 32MB也沒有助益,所以如果FB執行檔大小從接近8MB縮小到2mb多,cache的運用比較有效益(當然前提事項我這樣FB開開關關的...) 提到 CACHE 讓我想到,在有記憶體夠且有進 (disk)CACHE 的情況下,沒壓縮時系統 在重新執行 MozFB 時可以直接用 CACHE馬上 load and run 不用讀磁碟,而 UPX 後則不行。 每次都要進行解壓縮的動作。 另外下列 link 是一些 mozfb forum 上討論的文章:全是 upx 相關的。 http://forums.mozillazine.org/viewtopic ... hlight=upx http://forums.mozillazine.org/viewtopic ... hlight=upx http://forums.mozillazine.org/viewtopic ... hlight=upx http://forums.mozillazine.org/viewtopic ... hlight=upx 而 http://forums.mozillazine.org/viewtopic ... x&start=10 wget 也是用「negative effect on the performance」來稱之。 |
第 1 頁 (共 1 頁) | 所有顯示的時間為 UTC + 8 小時 |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |