Mark5347 wrote:
哇!好久沒看到這種直...(恕刪)
手有點癢....818pro刷Touch繁中版也有點想要插一卡....^_^"
後註：啊! 縮小pagepool....touchflo加上德儀小心臟.....還速看看就好囉^_^|||
但是 page pool 又是拿來做啥用的呢?
過去 PDA 都是用 NOR Flash, 所以 code 也都直接在 Flash 上 XIP, 因此並沒有這類的需求.
但是後來 NAND Flash/MDOC 開始起來, 由於這一類的 memory 無法 XIP, 因此 code and data 都需要 copy to RAM 才可以 RUN, 但假如一開始就全部 loading to RAM 一來 launch time 會變久, 二來也浪費, 所以就會有 demand paging 的需求.
也就是 App 被 launched 時, 可能只 launched 一小部份, 之後再需要的時後再依照 demand page-in, 而為了限制 page-in 的 size, 所以 OS Kernel 也只 pre-allocate 一個 pre-defined 的 pool size (像是 cache 一樣) 來給這些 demang paging-in, 而當 pool 滿的時後, 就會有倒霉鬼被 page-out. 萬一之後這些 code or data 又有需要, 那又要再 page-in 一次; 要是 page missed 很頻繁, 那種個 OS 光是在 page-in 就會花掉不少時間, performance 也慢了不少.
另外假如 App 是在 file system 裡, 不管是在 external Storage or copy 到 internal file system, 那也都會需要用掉 page pool.
那到底 page pool 要多少才是何理呢?
這其實要看情況而定, 基本上是 越多的 App 的 system, 會需要越多的 page pool 以維持一定的 performance, 但假如 program memory 是更 urgent 的 issue, 那適度的犧牲 page-pool size 也是一種 trade off.
以下是一個啥 3rd part app 都沒有的 system 所做的 testing
The following table shows an example of data that was collected for a reference Windows Mobile 6 Standard platform:
| Paging pool size | 3.0 MB | 3.5 MB | 4 .0 MB | 4.5 MB | 5.0 MB | 6.0 MB |
| Boot time | 38.1 seconds | 37.4 seconds |
34.6 seconds |
31.2 seconds |
29.7 seconds | 28.4 seconds |
| Inbox launch |
3.31 seconds |
3.20 seconds |
2.77 seconds |
2.66 seconds |
2.59 seconds |
2.45 seconds |
| Contacts launch | 1.72 seconds |
1.62 seconds |
1.41 seconds |
1.20 seconds |
1.16 seconds |
1.15 seconds |
然後就看起來似乎是 4.5MB 時會有一個 good balance for pool size and performance, 不過呢, 要是 system 裡的 App 大增, 那就不是這麼一回事了, 可是卻很少有廠商針對這方面去做 optimization 的 fine tune.
這個 size 其實是在 kernel 裡決定的, 或許 OEM/ODM 可以試著讓這個 variable 透過某種方式被 configure, 這樣大家就不用一直改 ROM 了.
情況是 因為 RAM 就是那麼大, 假如 pool size 變大, program memory 就變小, 反之亦然.
那就看 這個 App 對於 pool size 比較需求大 還是 program memory.
也就是說 通常 App size 大的 (EXE or DLL file total size 大的) 那通常會對 pool size 有需求
另外一方面 假如這個 App 因為 有較多的 program memory 可以多 cache 一些 data 的 memory, 來增加 performance 那就是對 program memory 有需求.
當然也有可能兩者都是...
所以最好的情況是, 設計一連串的 test case, 然後在不同的 pool size configuration 下做 benchmark test, 以得到一個最佳的 solution, 但這是需要花不少時間來完成的.
Okay, 另外可能有人會問, 那怎麼不做成 auto 的就好了, 跟據情況 poolsize 自動變大變小.
這的確是有此需求, 不過很不幸的是這到 Windows CE 6.0 的 kernel 才有這樣的 feature, 可是 WM5 or 6 都還是 base on CE5 kernel, 所以最快也要等到 Photon (the succession of Crossbow) 才有可能發生 到時後是 WM7 還是又搞個啥名子 WM Vista? 就不得而知了.
cdplayerxp wrote:
請問這個意思是說,雖然記憶體釋放了,變大了,
但跑程式並沒有比較快,反而變慢了的意思嗎?
內文搜尋
從 APP 打開
X