cache
を調べましたが、キャッシュにいくつかの問題が見つかりましたが、私が求めているものではありません。約1000行の文法を使用して、ユーザーが提供したかなり重い(500KB)テキストを解析しています。
{cache: true}
を渡すとき..。--max-old-space-size=3000
を使用)を使用するように指示すると、ヒープは2.5GBに増加し、解析は12秒で成功します。{cache: false}
を渡すと、予想どおり、クロックの解析は10秒でわずかに速くなり(非病理学的な場合)、メモリ使用量が膨らむことはありません。これはユーザーデータであり、サーバーリソースが限られているため、ノードをバンプしてX GBのヒープを使用することはできません。明日は、X + 1GBのヒープを必要とする1MBのユーザーデータを取得する可能性があります。 そしてもちろん、私が出会った「病的な場合の指数関数的な解析時間を避ける」ために、可能な限り{cache: true}
を使い続けたいと思います。
どのようなアプローチをお勧めしますか?
{cache: true}
使用法を切り替えることを検討しています。 それは私により多くのCPU使用率を要します、しかし少なくとも私はOOMしません。PEG.jsをありがとう! 🙂
指数関数的な構文解析時間は非常に病的な場合に発生するものであり、そこで文法を書き直すことをお勧めします。
https://github.com/sirthias/pegdown/issues/43#issuecomment-18469752を検討して
(私は寄稿者ではありません)
@ polkovnikov-phが指摘したように、病理学的なケースを扱う文法の部分を書き直すのが最善ですが、OOMケースをヒットし続ける場合は、あなた(@ronjouch)が提案したことを行う方が良いかもしれません。 入力のサイズに基づいて_cache_オプションを切り替えます: cache: input.length >= 250000
この後(ユーザーが提供したテキストにアクセスできる場合のみ)、OOMケースにヒットする入力を調べて一般的な病理学的ケースを見つけ、文法を更新してこれらを明示的に処理し、OOMケースの数を減らすことをお勧めします。あなたのアプリを打つ。
それでもOOMケースに頻繁に遭遇し、文法を書き直すだけでなく、ツールチェーンに追加のパス(またはいくつか)を追加することをいとわない場合は、次のいずれかの方法を試すことをお勧めします。
@ polkovnikov-ph @futagozaアドバイスをお返しするために時間を