您說不想引起爭論, 確又特別點出了這點出來
這不免讓人覺得多此一舉吧?
隨便找個Hole指責別人的邏輯,
您覺得您這樣的邏輯比較高明嗎?
例子我不想去解讀, 只會更落入爭辯
我也只想就Mozilla這個問題說明而已
「公司化就是營利事業」是沒錯
但是Mozilla的型態, 營利是交給基金會
幫助開發Firefox, 就這樣而已


我無所謂, 要刪便刪吧, 反正我不是出來吵鬧的...

別輕言砍文的啦x_x；討論設計理念是好事啊，這種事總會容易有爭論滴.....

就算1.5這些設計理念上的"缺陷"是事實，對我而言也不至於到難以接受的程度；又何況1.5的好處我是真的有感受到，算是瑕不掩瑜啦。如果因此不願下升級的決定我是完全可以理解的，究竟環境不同需求也不同，沒有什麼升或不升就不值得的事吧～

我個人是認為Firefox1.5是很值得討論的話題，會談到的層面很
廣也是必然的，因為它並不只是一個版本號的問題，它可是一個
Brower在行為模式上的革命性改變啊！它的新工作方式，不論短
期的將來是成是敗，都會對未來所新出現的其它Brower產生巨大
的影響力。

也許我比較健忘吧…自從有網景和IE兩大主流Browser以來，除
了IE在M$手中後來想要自己另建標準化之外，我還想不出來自從
那時以來，有何載入行為模式革命性的改變。

這個主題要怎樣開題也困難，又限於論壇的貼文模式如同從前的
程式寫作，它是直線進行的，無法像OOP般產生子系統，否則在
具有子系統的方式下，從各個不同角度去探討，各走各的子系統
談下去，會很清晰而且很有條理。

如果單純回到要不要用1.5版，就像我前面所說，就像玩Game
樣，裝下去也不會出人命，不裝也不至於沒有未來的新版可用。
我個人安裝了一套供家人使用，他們的感覺不錯。何況他們在上
網時是超級專心，根本沒有多工的困擾。而我的電腦一台有多工
的問題感覺不是很合適，另台NAT硬體不足也不合適，當然不升
級。

如果只對於我個人來說，是個很簡單的選擇也不用想太多。會想
談這個話題，相信是因大家關心的層面都提升到較深遠的原因。
如果只淺談它是快還是慢，我想也不值得貼在這討論的。

Firefox1.5的設計理念，以我的說法，它是一個十分大膽的方向
改造。說不定在Mozilla內部的Programers，都曾為此方向打過
一架都很難講。

革命性的改變總是需要極大的膽量，一般人總覺得瘋子是社會的
阻礙，所謂的正常會排斥瘋子，但法國哲學家Foucault在《瘋癲
與文明》中就說瘋癲才是文明的現象。文明大半是由瘋癲所造
成。當然，也許他真的瘋了；但也許他真的看得太遠了，Who
knows？

另外我也想過，Programers為何不建立一個釋放bfcache的功能
？我在紙上畫了半天，發現這在記憶體中是個很危險的動作。在
Browser同時直接從RAM中讀取並進行reflow和render時，到底
要怎樣分辨哪些位址可以安全釋放？哪些位址在釋放過程中會造
成Crash？我覺得好難啊…我想這是Firefox要完全關閉才能放掉
bfcache的原因吧…至少目前在這一點上面有盲點在。

我相信很多問題不是只有我們在思考。我曾提出一個說法就是：
當你在思考一件事時，地球上總至少有一個人和你同時在思考同
一個問題。這也是從前諾貝爾獎都是獨得，而現今常常好幾位不
同單位學者共分的原因。所以，我相信很多地球上其它地方的
User目前也在想我們在想的問題呢…或許人家還是在大雪中的半
夜研究思考呢…

不認同這個想法
這單純是Data Structure 與 Performance的角力
可以這麼想
把每個Tab是一個Session, 每個Session有Back/Current/Forward的頁面, 需要儲存
而每個頁面有需要render的資料(frame objects)
就會像一個樹狀結構 MainWindow - Tab - Frame - Frame Objects
每個Layer有每個Layer需要處理的資訊
bottle neck是把文字的頁面, 經過parsing 轉化成Frame Objects
以便於畫在顯示視窗上
同步處理得當, 釋放記憶體並並不會Crash
在這之下底層又牽扯了
1.In memory cache
2.file cache

一切的問題在於瀏覽速度
如果每個頁面都容忍重新從網路下載->parsing->rendering
一切就都沒問題了, 但是, 這樣使用者會覺得很慢..

釋放一個Frame, 當B/F 處理時就會需要reload
更甚者, 在於假設正在release memory, 正巧B/F到時, 該如何?
這是屬於Sync的問題了
可以有很多設計方式, 像是:
1.等到release後, 重新reload
2.保有現有的頁面資料, 載入缺乏的資料

1.毫無疑問的比較沒問題,
2.就得考慮很多問題, 像是版本問題, (可能夾雜了新舊的網頁資料)
另外就是partial parsing, 否則完整parsing跟重新載入頁面沒甚麼差別

Firefox該作的是
1.分析使用者行為, 將閒置過久的頁面釋放
2.提供使用者設定B/F頁面In Memory Cache的最大深度
3.將B/F的Frame Object以Compressed型式存在在記憶體中



人們常遇到的問題才會有人在想.......

您的確很強。這個思路是不是假設在靜態的情況下，網卡也沒解
封進RAM，使用也都沒有正在rendering某一些Frame Objcts？



File cache早已經過索引化，釋放早不是問題。問題就在於你認
為in-memory釋放真的如此容易？目前所有作業系統Thirdparty
的in-memory釋放程式中，您認為有哪一個可以在100次set
free動作中保證系統不Crash？



Sync在各種狀況中能做到某個高精度就很強了。



第一個方案應該是比較容易達成。第二個方案我想過，但光是觀
察我自己的閱讀行為（已經算很規則）都很難判定，因為隨閱讀
不同的內容會有很大的差異化，只能說是不得已的備選方案。第
三個方案又要涉及速度/記憶體用量，你在Decompress時也要
有更大的暫存空間吧？那記憶體使用量不是更大？



我願讓真理的光環歸於您…我只是把它當成一種感想。

請不要把系統記憶體管理
與單一Process的記憶體管理混為一談

對於OS層面的MM, 要做到兩個層面
1.Physical Memory Management
2.Process Memory Control

其中1.為實體記憶體, 這是直接由OS控制的
2.通常為Virtual Memory Address所表示, 不一定是在實體記憶體內

所以對於每一Process而言, 都不會感受到各自的存在, 都各自有著自己的Flat Memory Address Space
而OS要作的就是以Page為單位管理所有Process的虛擬記憶體空間對應到記憶體和Swap的位置

而Firefox需要控制的是自己使用記憶體的量, 跟OS無關

所以牽扯這個例子並不恰當
因為這類的程式已經以Module or Hook的方式介入OS的MM機制

1.Sync 再強, 都有相當的Overhead
2.Decompress需要的只是"原有的空間", 目前FF都以Uncompress的資料形式, 儲存在記憶體中, 解壓縮後就是要顯示的資料, 不會"比較大", 同一時間內, 只有比較接近的B/F頁面資料需要decompress,
其他的資料以compressed方式存在記憶體中, 可大大降低記憶體用量.

這麼說好了, 假設一個Tab內有10個B/C/F的Frame, 各自有一張1024*768的圖形
若使用的壓縮率為3:1, 假設僅有B/C/F各一張需要uncompressed
若都以Uncompressed的圖形資料存放->1024*768*3*10 約為21MB
若採用壓縮方式
1024*768*3*3 + 1024*768*3*7/3 約為 11 MB
(如果是針對資料型式壓縮, 比率會更高)

這類的作法
用Thread + Pipeline like的方式就可以做到, Sync沒問題....

既然你這麼認真，我就很誠懇的想：

一）你指我對單一Process的記憶體管理與系統混淆，其實不是。
差別是您的想法比較理想化，對X86能不能做到你設想的那麼分
明，我有待思考。這一點我願意承認無法提出很周全的思路，去
承認到底你是對的，還是我顧慮的比較多。因我不認為在所有OS
上可以使用同一個模型。

二）Decompress需要的只是"原有的空間"，是不是最好再仔細
想一下？你不需要使用新的暫存器嗎？這個有問題。

三）你用三張圖片的模型來解釋我是可以理解，在你認真解說之
前我已經想過這部分。但你是建立在單一Tab上，以及比較接近
的B/F，我覺得太單純化了。而使用者行為並不是那麼單純的啊…
另外就是Decompress時間，無法事先去評估。您想目前的使用
野心是很大的，又要B/F快的像電影，又要每個Layer可以拉來拉
去…這個模型是否可以真的在速度/記憶體用量間優化，我覺得很
難去評估出它實做之下兩者間的平衡點在哪裡。

不過你的口氣變溫和了我也很高興，另外就是建設性想法總比沒
想法要好上太多，提供給Mozilla.org參考看看如何？讓他們也想
想！

並不完全是OS平台, Modern Hardware平台都提供了記憶體管理相關的硬體, 方便OS實作
另外就是因為x86(386之後)都提供了page的管理, 才更能夠如此作

之前上面那些不是我一個人可以胡謅或信口開河來的
這部份是Modern OS所提供的, OS的教科書都有提到
Process內的記憶體使用就不提了, 這是Programmer要注意的
OS方面若您對這方面有興趣, 不妨看一下下列的書

1.Computer Architecture - A Quantitative Approach by Hennessy Patterson
2.Operating System Concepts
以上兩本是教科書
如果對於記憶體管理, 實務有興趣
http://www.phptr.com/promotions/promoti ... dir=1&rl=1
有一本Understanding Linux Virtual Memory Manager 值得一看


1.Tab資料是依附在Tab上, 不會任意更動, 因此並不複雜...
只是要作的深度的控制, 以及Frame-Object的個別處理
2.decompress 時間, 遠比swap少
(試想bmp和jpg的大圖比較.., bmp因為讀取慢, 所以顯示較慢, 儘管資料不需解壓縮)

要最快, 就必須有無限制的實體記憶體空間
如果沒有, 作可控制性和智慧型調整以及使用者設定是必要的
這些都會造成效能的損耗
然而任何的解決方案都只是在找最佳損益點...
現今硬體, CPU快, 硬碟慢, 所以用多餘的CPU換取空間是值得的

parisian和champ兩位兄臺（呵呵，兩位的id都和法國／法語有關呢）談的內容頗深入了，可否容我用比較普及的語言層次問個問題？

我們在Firefox 1.5釋出之前所期待的，還有Firefox本身定下的目標，似乎就是希望Firefox也能快速地像其他瀏覽器一樣切換上、下一頁的瀏覽吧，其中Opera應該可說是很重大的假想敵。討論到這步田地，我也蠻想知道，那麼Opera是怎麼做到高速翻頁的？IE呢？還有，一開始聽到Firefox即將在1.5改變上／下一頁載入的行為，我以為改變的方式是不要再從伺服器上重新下載一次資料，而是直接從cache當中render，這樣就可以變快，看來不是這個意思囉？是否Firefox原本就是從cache中render，而現在只是要讓cache存在記憶體中，而非從硬碟中再抓？

_________________
不努力的話，就會死在這裡，或是死在那裡。

Opera的Back/Forward是不會去存取網路是真的
我想, 以Opera公司有各個平台到Embedded/Mobile產品來看
Opera的內部資料結構和整個系統架構一定有其獨到之處
既然針對Embedded市場, Opera的記憶體管理和使用一定很嚴苛
這可能得由Opera本身來揭密才行
從Cache存放資料以便快速的Back/Forward已經不是秘訣
我想重點還是在資料的存放方式和資源的有效利用

我用Firefox 1.5
但是我都給我朋友用1.0.7的
因為擴充套件的問題啊~~
有Powerpack比較方便~

"資料結構"啊.........

作為一個keyword我是贊同啦.......只是這一科對我來說.......太艱深了

Opera我不了解。我這人一向懂什麼說什麼，不懂不吹牛，所以
我看Champ回答就很夠了。我不了解它的原因，一方面也是因為
我對它沒興趣的關係。另一方面就如同Champ所說這種獨到技術
保密到家，你看不到原始碼的話，除非此方面國際級的教授，大
概才可能了解它較明確的工作原理。

你提至Firefox1.5 Cache的方向我有點看不太懂，覺得好像有些
Cache你指的是File Cache有些又是In-memory Cache…我有
點看了眼花。部分我是看懂，像你說舊版是否本來就從Cache中
render？可以這麼說：它是的。但它主要還是用在你Top-Level
上面以及已經滾動過頁面，還有就是下層非JS部分以外短時內剛
開啟的頁面，如果你上下滾動過的話也同樣會先保存在那邊，至
於其它的就在File Cache等你要讀取時再叫回來的，但其實File
Cache早就寫進去了，它比IE優良的是索引目錄設計較條理分
明，以及Compress後的安全性；而IE是一直延續古老物件暫存
方式，索引設計老式但大家很清楚它暫存是Uncompressed。

另外其實舊B/F中的部分也是一直都在In-memory Cache中的，
太遠的就（應該）會放掉，這端看Cache參數是如何設定，會有
不同的比例。那我覺得您在1.5版所增加的疑問，應是出於您沒去
看我說的Using Firefox 1.5 Caching官方原文件所致。bfcache
就更進一步了，那這部分我已經重述過很多次它的行為模式，就
不再提，我想您應該記得才是。但在這裡我也要說，我還沒有去
實際研究過bfcache和原有的In-memory Cache之間工作是如何
重新分配。也或許後者是扮演解封後直接存放網頁物件之處。但
這在官方文件裡並沒有說清楚，要去看1.5的原碼才會知道是否如
此。而bfcache功能，就專著在目前大家所看到，除啟動外的加快
部分。

至於舊版從In-memory載入動作會包含repush/reflow和render
部分，而bfcache就都已經全部完成，只是Standby在那等著你把
頁面翻出來而已，這也就是它多吃記憶體的主要原因。至於什麼部
分會從File Cache中再抓，就只有很少很少的部分了，但到底是哪
些，我想這就關乎官方文件內所提的：六大不進行bfcache的部分
。至於何種情況1.5版會再進行Reload，或何種情形完全不進行
bfcache動作，我也有把這些中的部分翻譯出來，看了就會明白。
您所質疑的「看來還是要Reload」其實在絕大部分情況，真的在
1.5版上的全新動作原理之下，是完全不必的再進行的。

如果還是不覺得完整，就要進去看完整官方文件，因為我只是把對
於User較重要的地方節錄出來而已。