奇妙なJavaScript / Node.jsのパフォーマンスの問題

user7636880

現在、私は非常に奇妙なパフォーマンスの問題に苦しんでいます。SlowHeapにかかる平均は1448.623msですが、FastHeapに必要なのは550.425msだけです。私はそれを何度も見てきましたが、2つの違いは、最初の要素が_arrの先頭に「未定義」の要素を使用し、2番目の要素が使用しないことだけです。ただし、どちらも同じ操作を実行します。下のコードで確認したこと。

この問題に光を当てることができる人はいますか?

let slowHeapOperationCount = 0
let fastHeapOperationCount = 0

let slowHeapExchanged = []
let fastHeapExchanged = []

function SlowHeap(cmp = (a, b) => a > b ? 1 : a < b ? -1 : 0) {
    this.cmp = cmp
    this._arr = [undefined]
    this.size = 0
}
function FastHeap(cmp = (a, b) => a > b ? 1 : a < b ? -1 : 0) {
    this.cmp = cmp
    this._arr = []
    this.size = 0
}

SlowHeap.prototype.bubbleUp = function (cmp, _arr, val) {
    let idxNr = this.size, parentIdxNr = idxNr >> 1
    while (idxNr > 0 && cmp(_arr[parentIdxNr], val) > 0) {
        slowHeapExchanged.push([_arr[parentIdxNr], val])

        _arr[idxNr] = _arr[parentIdxNr]
        _arr[parentIdxNr] = val

        idxNr = parentIdxNr
        parentIdxNr = idxNr >> 1

        slowHeapOperationCount++
    }
}
FastHeap.prototype.bubbleUp = function (cmp, _arr, val) {
    var idxNr = this.size,
        parentIdxNr = ((idxNr - 1) / 2) | 0;

    while (idxNr > 0 && cmp(_arr[parentIdxNr], val) > 0) {
        fastHeapExchanged.push([_arr[parentIdxNr], val])

        _arr[idxNr] = _arr[parentIdxNr];
        _arr[parentIdxNr] = val;

        idxNr = parentIdxNr;
        parentIdxNr = ((idxNr - 1) / 2) | 0;

        fastHeapOperationCount++
    }
}

SlowHeap.prototype.push = function (val) {
    ++this.size
    this._arr.push(val)
    this.bubbleUp(this.cmp, this._arr, val)
    return this.size
}
FastHeap.prototype.push = function (val) {
    this._arr.push(val);
    this.bubbleUp(this.cmp, this._arr, val);
    return ++this.size;
}

const itemCount = 4000000

const slowHeap = new SlowHeap()
const fastHeap = new FastHeap()

//
// Append the same Number Collection to each Heap:
const numberCollection = []

for (let idxNr = 0; idxNr < itemCount; idxNr++) numberCollection.push(Math.random())

//
// Benchmark for the Slow Heap:
console.time('SlowHeap')

for (let idxNr = 0; idxNr < itemCount; idxNr++) {
    slowHeap.push(numberCollection[idxNr])
}

console.timeEnd('SlowHeap')

//
// Benchmark for the Fast Heap:
console.time('FastHeap')

for (let idxNr = 0; idxNr < itemCount; idxNr++) {
    fastHeap.push(numberCollection[idxNr])
}

console.timeEnd('FastHeap')

//
// Verify the "_arr" from the Slow Heap against the Fast Heap:
for (let idxNr = 0; idxNr < itemCount; idxNr++) {
    if (slowHeap._arr[idxNr + 1] !== fastHeap._arr[idxNr]) console.log('Unequal value found!')
}

if (slowHeapExchanged.length !== fastHeapExchanged.length) console.log('Help! Comp. is not equal.')

for (let idxNr = 0, maxNr = slowHeapExchanged.length; idxNr < maxNr; idxNr++) {
    if (slowHeapExchanged[idxNr][0] !== fastHeapExchanged[idxNr][0] || slowHeapExchanged[idxNr][1] !== fastHeapExchanged[idxNr][1]) {
        console.log('Help!')
    }
}

console.log(slowHeapOperationCount)
console.log(fastHeapOperationCount)
robertklep

詳細については何も知りませんが、V8最適化が有効化/無効化されているようです。に置き換えるundefined0.0SlowHeapそれほど遅くはありません(実際、FastHeapよりも高速です)。

私の推測では、配列をfloat(Math.random())で埋めているので、配列にすべて同じタイプのアイテムが含まれている限り、実行できる最適化があります。

型の不一致(undefinedfloatではない)を導入すると、V8はおそらくより一般的な型の配列に切り替えて、最適化を控える必要があるかもしれません。

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集
0

コメントを追加

0

関連記事

分類Dev

奇妙なNode.jsのパフォーマンス

分類Dev

DataReaderのパフォーマンスの問題、奇妙な動作

分類Dev

奇妙なKinecticjsのパフォーマンスの問題

分類Dev

選択可能なRecyclerViewのパフォーマンスの問題

分類Dev

yaml-cppの主なパフォーマンスの問題

分類Dev

node.jsとASP.NET Coreのパフォーマンステストの予期しない結果

分類Dev

予期しないパフォーマンスの問題

分類Dev

Node.jsの奇妙なTypeError

分類Dev

9.6アップグレード後のpostgresqlINクエリでの奇妙なパフォーマンスの問題

分類Dev

javascript.jsの代わりにjavascript.phpを使用したJavascriptのパフォーマンスの問題

分類Dev

DjangoAdminの重大なパフォーマンスの問題-外部キーラベル

分類Dev

PostgreSQLでは、citextのパフォーマンスに関する奇妙な問題はありますか?

分類Dev

javascriptオブジェクトのパフォーマンス関連の問題

分類Dev

Springの@Autowiredは大きなパフォーマンスの問題ですか?

分類Dev

Coldfusion10で再現可能なCFQUERYPARAMのパフォーマンスの問題

分類Dev

SQLServerクエリの断続的なパフォーマンスの問題

分類Dev

単純なクエリでのパフォーマンスの問題

分類Dev

Node.Jsの奇妙なエラー

分類Dev

単純な計算によるパフォーマンスの問題

分類Dev

MongooseとNode.jsでのJavaScriptスコープの問題

分類Dev

Node.jsのパフォーマンス上の利点

分類Dev

Qt:パフォーマンスの問題のない(カスタム)QWidgetsのリスト

分類Dev

mongodbの大きなネストされたデータのクエリパフォーマンスの問題

分類Dev

UICollectionビューのスクロール可能な年ビュー:パフォーマンスの問題

分類Dev

zeromqとPythonとJavaのnode.jsパフォーマンス

分類Dev

javascriptオートコンプリートのパフォーマンスの問題

分類Dev

C ++での大きなCSVファイルのパフォーマンスの問題を読み込む

分類Dev

D3力指向グラフ:複雑なグラフのパフォーマンスの問題

分類Dev

再帰的なORMクラスでのSpringリポジトリのパフォーマンスの問題

Related 関連記事

  1. 1

    奇妙なNode.jsのパフォーマンス

  2. 2

    DataReaderのパフォーマンスの問題、奇妙な動作

  3. 3

    奇妙なKinecticjsのパフォーマンスの問題

  4. 4

    選択可能なRecyclerViewのパフォーマンスの問題

  5. 5

    yaml-cppの主なパフォーマンスの問題

  6. 6

    node.jsとASP.NET Coreのパフォーマンステストの予期しない結果

  7. 7

    予期しないパフォーマンスの問題

  8. 8

    Node.jsの奇妙なTypeError

  9. 9

    9.6アップグレード後のpostgresqlINクエリでの奇妙なパフォーマンスの問題

  10. 10

    javascript.jsの代わりにjavascript.phpを使用したJavascriptのパフォーマンスの問題

  11. 11

    DjangoAdminの重大なパフォーマンスの問題-外部キーラベル

  12. 12

    PostgreSQLでは、citextのパフォーマンスに関する奇妙な問題はありますか?

  13. 13

    javascriptオブジェクトのパフォーマンス関連の問題

  14. 14

    Springの@Autowiredは大きなパフォーマンスの問題ですか?

  15. 15

    Coldfusion10で再現可能なCFQUERYPARAMのパフォーマンスの問題

  16. 16

    SQLServerクエリの断続的なパフォーマンスの問題

  17. 17

    単純なクエリでのパフォーマンスの問題

  18. 18

    Node.Jsの奇妙なエラー

  19. 19

    単純な計算によるパフォーマンスの問題

  20. 20

    MongooseとNode.jsでのJavaScriptスコープの問題

  21. 21

    Node.jsのパフォーマンス上の利点

  22. 22

    Qt:パフォーマンスの問題のない(カスタム)QWidgetsのリスト

  23. 23

    mongodbの大きなネストされたデータのクエリパフォーマンスの問題

  24. 24

    UICollectionビューのスクロール可能な年ビュー:パフォーマンスの問題

  25. 25

    zeromqとPythonとJavaのnode.jsパフォーマンス

  26. 26

    javascriptオートコンプリートのパフォーマンスの問題

  27. 27

    C ++での大きなCSVファイルのパフォーマンスの問題を読み込む

  28. 28

    D3力指向グラフ:複雑なグラフのパフォーマンスの問題

  29. 29

    再帰的なORMクラスでのSpringリポジトリのパフォーマンスの問題

ホットタグ

アーカイブ