首頁猿問在javascript-內(nèi)存考慮事...

在javascript-內(nèi)存考慮事項中遞歸構(gòu)建承諾鏈

JavaScript

函數(shù)式編程 2019-10-05 07:07:23

在javascript-內(nèi)存考慮事項中遞歸構(gòu)建承諾鏈在……里面這個答案，承諾鏈是遞歸構(gòu)建的。略為簡化，我們有：function foo() { function doo() { // always return a promise if (/* more to do */) { return doSomethingAsync().then(doo); } else { return Promise.resolve(); } } return doo(); // returns a promise}這可能會導(dǎo)致調(diào)用堆棧。和一條承諾鏈-“深”和“寬”。我預(yù)計內(nèi)存峰值會比執(zhí)行遞歸或單獨構(gòu)建承諾鏈更大。是這樣嗎？有沒有人考慮過以這種方式構(gòu)建鏈的記憶問題？記憶消耗在承諾庫之間會有所不同嗎？

查看完整描述

3 回答

溫溫醬

TA貢獻1752條經(jīng)驗獲得超4個贊

過早的優(yōu)化是不好的，找出性能差異的真正方法是測試您的代碼，你不應(yīng)該擔(dān)心這個問題(我只需要做一次，我已經(jīng)為至少100個項目做出了承諾)。

是這樣嗎？

是這些承諾必須“記住”它們遵循的內(nèi)容，如果您對10000的承諾執(zhí)行此操作，您將有一個10000長的承諾鏈，如果您不這樣做，您就不會(例如，使用遞歸)-對于任何排隊流控制，這都是正確的。

如果你必須跟蹤10000件額外的東西(操作)，那么你需要為它保留內(nèi)存，這需要時間，如果這個數(shù)字是一百萬，它可能是不可行的。各圖書館的情況各不相同。

有沒有人考慮過以這種方式構(gòu)建鏈的記憶問題？

當(dāng)然，這是一個很大的問題，也是使用類似于Promise.each在像藍知更鳥這樣的圖書館里then能干的鏈子。

為了避免這種風(fēng)格，我個人在代碼中使用了一個快速應(yīng)用程序，該應(yīng)用程序只遍歷VM中的所有文件-但在絕大多數(shù)情況下，這是一個沒有問題的問題。

記憶消耗在承諾庫之間會有所不同嗎？

是的，非常重要。例如，藍鳥3.0將不會分配額外的隊列，如果它檢測到承諾操作已經(jīng)是異步的(例如，如果它以Promise.Delay開頭)，并且只會同步執(zhí)行(因為異步保證已經(jīng)被保留)。

這意味著，我在對第一個問題的回答中所聲稱的并不總是正確的(但在常規(guī)用例中是正確的)：除非提供內(nèi)部支持，否則本機承諾永遠無法做到這一點。

再說一遍-這并不令人驚訝，因為承諾庫之間的差別是數(shù)量級的。

反對回復(fù) 2019-10-13

慕尼黑8549860

TA貢獻1818條經(jīng)驗獲得超11個贊

我剛出了一個可能有助于解決問題的黑客：不要在最后一次做遞歸then，更確切地說，在最后一次做這件事catch，因為catch不在解決鏈之外。使用您的例子，應(yīng)該是這樣的：

function foo() {
    function doo() {
        // always return a promise
        if (/* more to do */) {
            return doSomethingAsync().then(function(){
                        throw "next";
                    }).catch(function(err) {
                        if (err == "next") doo();
                    })
        } else {
            return Promise.resolve();
        }
    }
    return doo(); // returns a promise}

反對回復(fù) 2019-10-13