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/