摘要:至今天年月日,這個工具的實(shí)現(xiàn)源碼思想是極其相似的,基本上,只要閱讀了其中一個源碼,也就了解了另外一個的實(shí)現(xiàn)。都對返回的緩存函數(shù)進(jìn)行了參數(shù)注入這是一個極大提升性能的方法。不同點(diǎn)使用了無的對象,使用了普通對象這一點(diǎn)性能上相差不多。
至今天(2018年9月7日),這2個工具的實(shí)現(xiàn)源碼思想是極其相似的,基本上,只要閱讀了其中一個源碼,也就了解了另外一個的實(shí)現(xiàn)。
fast-memoize導(dǎo)圖:
初識大概說說它們的實(shí)現(xiàn)思路:
定義緩存結(jié)構(gòu),其中fast使用了無prototype的對象,nano使用了普通對象。
定義序列化方法:當(dāng)檢測到是單參數(shù)時(shí),都是選擇JSON.stringify,而多個參數(shù),兩者有不同(后面再說)。
定義策略:也就是緩存的具體方法,其實(shí)很簡單,就是對當(dāng)前緩存結(jié)構(gòu)查找,找到就返回,找不到就重新運(yùn)行,
兩者都使用了bind方法注入?yún)?shù),可以省去運(yùn)行時(shí)再去查找參數(shù)。
接著分析兩者的異同:
相同處:
都使用了JSON.stringify作為序列化方法,因?yàn)樗窃摹?/p>
都對返回的緩存函數(shù)進(jìn)行了參數(shù)注入(這是一個極大提升性能的方法)。
對單參數(shù)還是多參數(shù)的判斷都是使用func.length(形參的數(shù)量判斷),因?yàn)?b>func.length比arguments.length這種動態(tài)判斷性能會好很多。
不同點(diǎn):
fast使用了無prototype的對象,nano使用了普通對象(這一點(diǎn)性能上相差不多)。
當(dāng)遇到多個參數(shù)時(shí),fast還是繼續(xù)對arguments進(jìn)行序列化,而nano則復(fù)雜一點(diǎn),它通過用數(shù)組將每一次多個參數(shù)保存起來,
后續(xù)通過遍歷每個參數(shù)進(jìn)行全等對比===,判斷是否從緩存調(diào)取結(jié)果。
同樣是多個參數(shù),nano增加了一個參數(shù)max,可以讓用戶自定義需要進(jìn)行對比參數(shù)的長度。
深入接著看下第二點(diǎn)不同點(diǎn)的源碼:
主要看nano-memoize:
function multiple(f,k,v,eq,change,max=0,...args) { // 用來儲存i(當(dāng)前對比的參數(shù)索引)和緩存值 const rslt = {}; // k是一個專門存放多個參數(shù)的數(shù)組 格式類似 // [[...args],[...args],[...args]...] for(let i=0;i=0 ? rslt.i : v.length; if(change) { change(i); } // 如果緩存不存在就執(zhí)行func,存在直接返回緩存 return typeof rslt.v === "undefined" ? v[i] = f.call(this,...(k[i] = args)) : rslt.v; }
可以看出,這是通過2次遍歷,對 [[...args],[...args],[...args]...]這樣一種結(jié)構(gòu)比較,外層遍歷判斷l(xiāng)ength,
length相等才會進(jìn)入內(nèi)層遍歷,內(nèi)層遍歷就是逐個判斷了。
// 注入?yún)?shù),提升性能 f = multiple.bind( this, fn, k, v, // 逐個判斷方式默認(rèn)為 === equals || ((a,b) => a===b), // default to just a regular strict comparison (maxAge ? change.bind(this,v): null), // turn change logging on and bind to arg cache v maxArgs );
上面一段則是參數(shù)注入方式和默認(rèn)的對比方式。
總結(jié)一個表格總結(jié)兩者最大不同,假設(shè):
忽略===的執(zhí)行時(shí)間
使用的參數(shù)分為 引用相同 和 引用不同(但是深比較都為true)
例如:{x:1}和{x:1}
耗時(shí)操作 | 多個參數(shù)(引用相同) | 多個參數(shù)(引用不同) | ||
---|---|---|---|---|
狀態(tài) | 首次運(yùn)行 | 后續(xù)運(yùn)行 | 首次運(yùn)行 | 后續(xù)運(yùn)行 |
fast | 序列化+運(yùn)行函數(shù) | 序列化比較 | 序列化+運(yùn)行函數(shù) | 序列化比較 |
nano | 運(yùn)行函數(shù) | 0(===比較) | 運(yùn)行函數(shù) | 運(yùn)行函數(shù)(===比較失敗) |
源碼(帶注釋)倉庫
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/97543.html
摘要:至今天年月日,這個工具的實(shí)現(xiàn)源碼思想是極其相似的,基本上,只要閱讀了其中一個源碼,也就了解了另外一個的實(shí)現(xiàn)。都對返回的緩存函數(shù)進(jìn)行了參數(shù)注入這是一個極大提升性能的方法。不同點(diǎn)使用了無的對象,使用了普通對象這一點(diǎn)性能上相差不多。 至今天(2018年9月7日),這2個工具的實(shí)現(xiàn)源碼思想是極其相似的,基本上,只要閱讀了其中一個源碼,也就了解了另外一個的實(shí)現(xiàn)。 fast-memoize導(dǎo)圖: ...
摘要:巧前端基礎(chǔ)進(jìn)階全方位解讀前端掘金我們在學(xué)習(xí)的過程中,由于對一些概念理解得不是很清楚,但是又想要通過一些方式把它記下來,于是就很容易草率的給這些概念定下一些方便自己記憶的有偏差的結(jié)論。 計(jì)算機(jī)程序的思維邏輯 (83) - 并發(fā)總結(jié) - 掘金從65節(jié)到82節(jié),我們用了18篇文章討論并發(fā),本節(jié)進(jìn)行簡要總結(jié)。 多線程開發(fā)有兩個核心問題,一個是競爭,另一個是協(xié)作。競爭會出現(xiàn)線程安全問題,所以,本...
摘要:巧前端基礎(chǔ)進(jìn)階全方位解讀前端掘金我們在學(xué)習(xí)的過程中,由于對一些概念理解得不是很清楚,但是又想要通過一些方式把它記下來,于是就很容易草率的給這些概念定下一些方便自己記憶的有偏差的結(jié)論。 計(jì)算機(jī)程序的思維邏輯 (83) - 并發(fā)總結(jié) - 掘金從65節(jié)到82節(jié),我們用了18篇文章討論并發(fā),本節(jié)進(jìn)行簡要總結(jié)。 多線程開發(fā)有兩個核心問題,一個是競爭,另一個是協(xié)作。競爭會出現(xiàn)線程安全問題,所以,本...
摘要:歡迎來我的個人站點(diǎn)性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開啟性能優(yōu)化之旅高性能滾動及頁面渲染優(yōu)化理論寫法對壓縮率的影響唯快不破應(yīng)用的個優(yōu)化步驟進(jìn)階鵝廠大神用直出實(shí)現(xiàn)網(wǎng)頁瞬開緩存網(wǎng)頁性能管理詳解寫給后端程序員的緩存原理介紹年底補(bǔ)課緩存機(jī)制優(yōu)化動 歡迎來我的個人站點(diǎn) 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開啟性能優(yōu)化之旅 高性能滾動 scroll 及頁面渲染優(yōu)化 理論 | HTML寫法...
摘要:歡迎來我的個人站點(diǎn)性能優(yōu)化其他優(yōu)化瀏覽器關(guān)鍵渲染路徑開啟性能優(yōu)化之旅高性能滾動及頁面渲染優(yōu)化理論寫法對壓縮率的影響唯快不破應(yīng)用的個優(yōu)化步驟進(jìn)階鵝廠大神用直出實(shí)現(xiàn)網(wǎng)頁瞬開緩存網(wǎng)頁性能管理詳解寫給后端程序員的緩存原理介紹年底補(bǔ)課緩存機(jī)制優(yōu)化動 歡迎來我的個人站點(diǎn) 性能優(yōu)化 其他 優(yōu)化瀏覽器關(guān)鍵渲染路徑 - 開啟性能優(yōu)化之旅 高性能滾動 scroll 及頁面渲染優(yōu)化 理論 | HTML寫法...
閱讀 1320·2021-11-11 10:57
閱讀 3740·2021-09-07 10:10
閱讀 3455·2021-08-03 14:03
閱讀 3082·2019-08-30 13:45
閱讀 696·2019-08-29 11:19
閱讀 1052·2019-08-28 18:07
閱讀 3112·2019-08-26 13:55
閱讀 824·2019-08-26 12:17