向後端介面請求資料 返回 使用者資訊 以及一個 網站清單
使用者資訊 請求回來顯示了之後就沒有其他地方用了 但是用戶 網站列表 這個需要到處去用
在用 網站列表 的時候我是直接用回傳回來的資料物件還是新建一個物件把 網站列表 的資料放進去
如果用原始資料物件 那麼物件裡包含的使用者資訊等一些已經沒用了的資料就沒辦法被回收 不爽 還浪費記憶體…
你需要清楚的是，腳本語言程式設計解釋器附帶了記憶體回收機制，可以在 Chrome 的 Performance 中查看頁面的堆記憶體佔用和自動回收情況。
實際情況是，用於渲染頁面的資料量遠小於目前的機器閾值水準。舉例：在我的地圖庫 http://sinomap.ewind.us 中，對錶示中國地形在 2000 行水平的 JSON 數據，每個有 10 條內的簡單數字和 100 字內的字符串。以 60fps 的幀率全量對其做簡單計算，內存佔用也不過 30M 左右。所謂【浪費內存】的擔心在多數情況下是不切實際的。
新建資料物件再拷貝資料是最浪費資源的方案，包括 CPU 和 記憶體；
不處理直接使用原數據，稍微佔用記憶體；
取得原始資料後刪除無用數據，佔用 CPU 和 執行時間；比較而言，通常選 2 ，對使用者體驗而言，回應速度比記憶體重要，除非記憶體 OOM 。
你需要清楚的是，腳本語言程式設計解釋器附帶了記憶體回收機制，可以在 Chrome 的 Performance 中查看頁面的堆記憶體佔用和自動回收情況。
實際情況是，用於渲染頁面的資料量遠小於目前的機器閾值水準。舉例：在我的地圖庫 http://sinomap.ewind.us 中，對錶示中國地形在 2000 行水平的 JSON 數據，每個有 10 條內的簡單數字和 100 字內的字符串。以 60fps 的幀率全量對其做簡單計算，內存佔用也不過 30M 左右。所謂【浪費內存】的擔心在多數情況下是不切實際的。
新建資料物件再拷貝資料是最浪費資源的方案，包括 CPU 和 記憶體；
不處理直接使用原數據，稍微佔用記憶體；
取得原始資料後刪除無用數據，佔用 CPU 和 執行時間；
比較而言，通常選 2 ，對使用者體驗而言，回應速度比記憶體重要，除非記憶體 OOM 。