それは変です。 Nodeのバージョンは何ですか？

@ PatSmuk360 3.10.0のメモリプロファイルをテストして取得し、それが異なるかどうかを確認できますか？

最新バージョンの10（10.16.3）を実行しています。

前のヒープスナップショット：

後のヒープスナップショット：

また、ノード12.10.0を試してみましたが、シーケンシャルビルドのある時点で587 MBのメモリ使用量に達し、さらに悪化しているようです。

以前のCPUプロファイル：
CPU-20190916T133934.cpuprofile.zip

後のCPUプロファイル：
CPU-20190916T134917.cpuprofile.zip

@ PatSmuk360つまり、長短は、これらのバージョンの違いは、コードベースがES6構文に変換されたことです。 これは技術的には重大な変更ではないため、メジャーバージョンではありませんでした。

しかし...私の疑いは、オブジェクト/配列拡散構文のようなもののためのバベル変換のいくつかは、より冗長なES5バージョンよりも効率が悪いということです。 もともとノード6以降と互換性のあるトランスパイルパッケージをエクスポートしていたので、3.10.0をテストできるかどうか尋ねていたのですが、クラス構文を処理できない特定のライブラリとの

どのES5変換がうまく機能していないかを正確に把握できれば、理論的には、これらのBabelエクスポート設定をよりパフォーマンスの高いエクスポートに設定できます。

@ PatSmuk360ちなみに、split関数は何ですか？

@ matthew-deanそれはString.prototype.splitです。 Chrome devtoolsでプロファイルを開くと、色分けされたすべてのデータを確認できます。 ボトルネックを簡単に検査できるように、ソースとしてhttps://cdn.jsdelivr.net/npm/[email protected]/dist/less.cjs.jsにリンクするようにプロファイルを変更しようとしています。 *.cjs.jsから*.jsファイルに使用できるソースマップはありますか？ https://cdn.jsdelivr.net/npm/[email protected]/dist/less.min.js.mapファイルは.minファイルをES6ソースにマップしているようです。 たぶん、ソースマップを開発ツールにフィードして、トランスパイルがボトルネックを引き起こしている場所を特定できるようにすることができます。

特定のhttps://github.com/less/less.js/blob/cae5021358a5fca932c32ed071f652403d07def8/lib/less/source-map-output.js#L78のこの行には、CPU時間が長いようです。 しかし、それが実行する操作を考えると、それは私には場違いに思えません。

ヒーププロファイルの経験はあまりありませんが、私が目立つのは(closures), (system), (array), system / Context量の増加です。 これをCPUプロファイルに関連付けようとすると、これらのオブジェクトが増えると、ガベージコレクションに費やされる時間が大幅に増えるようです。

@kevinramharak一般に、深さが_n_のLessのようなASTを、CSSのようなシリアル化されたフラットな出力ツリーに変換するには、多くの一時的なオブジェクトの作成が必要です。 したがって、発生する可能性があるのは、特定の変換で、追加の_x_量のオブジェクトが追加されることです。 一時的にでも、各ノードがオブジェクトを2〜3倍作成し、ノード数にルールをフラット化する必要がある回数を掛けた指数関数的な効果を得ることができます...合計するとわかりました。 ES6構文を本質的にES5構文の構文糖衣として本質的に考えることは、おそらく一般的にはナイーブでした。 （JavaScript開発者は、おそらくこれについて一般的に罪を犯しているでしょう。）実際には、新しい構文をトランスパイルすると、パフォーマンスの低いES5パターンが作成される可能性があります。 開発者の99％にとって、これは大したことではありません。なぜなら、彼らは1秒間に数百または数千回そのコードを反復していないからです。 しかし、他に大きな変更はなかったので、これは何が起こっているかについての私の推測です。

@kevinramharak Re：ソース行-これは、元のLessパーサーが入力の行/列を追跡しないためです。したがって、ソースマッピングが追加された場合、元の行にマップする方法を理解するために、基本的に入力を行にチャンクする必要がありました。ソース。 これは4.x +では問題になりませんが、それが今そこで多くの時間を費やす理由は理にかなっています。

私はブラウザでless.min.jsを使用していますが、3.10.3は以前使用していた2.7.3よりも2倍遅くなっています。 ChromeとFirefoxの両方。

@ PatSmuk360このブランチをチェックできますか？ https://github.com/matthew-dean/less.js/tree/3.11.0

要するに、バベルのES5へのトランスパイルはちょっとひどいものであり、クラスをトランスパイルするために大量のObject.defineProperty呼び出しを使用します。 トランスピレーションをTypeScriptに切り替えました。これは、関数プロトタイプの出力が非常に優れています。

これはすべて問題なくダンディですが、これを実行した後、Lessのブラウザテストは非常に古くて古いPhantomJSを使用しているため実行されません。これまでのところ、誰も（私を含めて）PhantomJSからテストを正常に移行できていません。ヘッドレスクロームに。

ただし、一度に1つの問題があります。そのブランチのdistソースにメモリの問題がない場合は、ブラウザのテストである混乱に取り組むことができるかもしれません。

LessブラウザテストをHeadlessChromeに移行することができましたが、パフォーマンス/安定性の観点から、変換パイプラインを完全にBabelからTypeScriptに変更したため、安全にマージする前にユーザーからの多くのフィードバックが必要です。

現在のブランチはここで見つけることができます： https ：

それでも2.7より2倍遅い。

@alecplそれは良い情報ですが、3.11.0が3.10よりも改善されているかどうかを本当に知りたいです。

これについての奇妙なことは、_理論的には_、元のLessコードがLebabで変換されたことです。これは、Babelの反対であるはずです。 つまり、ES5-> ES6-> ES5はほぼ同じである必要がありますが、明らかにそうではありません。 したがって、ES6-> ES5コードが元のES5コードとどのように異なるかを調査する必要があります（他の誰かが時間を持っていない限り、サポートを歓迎します）。

@alecpl

そこで、さまざまなテストを実行し、ヘッドレスChromeで3.11.0対3.10.3対3.9.0対2.7.3のベンチマークを行うことに時間を費やしました。

Lessコンパイラがどのバージョンでも遅いという証拠は見つかりませんでした。ましてや2倍遅いという証拠もありません。 トランスパイル設定のために3.10.0の方がメモリのオーバーヘッドが多いことは事実であり、システムのスペースに制約があり、結果としてより多くのメモリスワップまたはより多くのGCを実行すると、速度が低下する可能性がありますか？ しかし、私はそれを確認することはできません。

3.11.0ブランチでgrunt benchmarkを実行して自分自身をテストできます。 個々の実行で異なる数値が報告される場合がありますが、十分な回数実行すると、時間がほぼ等しいことがわかります。 だから私はあなたがあなたのデータをどこで得ているのか分かりません。

@ PatSmuk360 3.11.0のメモリオーバーヘッドをテストできましたか？

私はあなたのコードを自分で作成しません。 nodejsは使用していません。 私が言及した2つの異なるバージョンのdistフォルダーからless.min.jsファイルを取得し、それらを自分のページで使用します。 次に、コンソールで、Lessコードによって出力されたタイミングが表示されます。 私の少ないコードは複数のファイルを使用し、出力ファイルは約100kBの縮小されたcssです。 これは「実際の」ベンチマークです。 Roundcubeコードについて話しています。

ChromeはFirefoxよりもはるかに高速ですが、どちらのバージョンの違いも似ています。

@alecplうーん....多分それはその特定のLessコードの特定の違いです。 ベンチマークが恣意的であることは事実です。 時間があれば、それらのLessファイルをベンチマークに追加します。

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 それ以上のアクティビティが発生しない場合は閉じられます。 貢献していただきありがとうございます。

簡単な更新を投稿したかっただけです。3.11.1を試しましたが、3.10.3と同じくらい遅いです。 これをテスト/プロファイリングするための代表的なベンチマークを作成できるかどうかを確認します。

3.11.1にアップグレードしましたが、同じメモリ消費の問題が発生しています。
適度なサイズのプロジェクトでは、webpackとless-loaderを介してビルドするのに最大600MBのRAMが必要です。

ヒープ割り当てのタイムラインをとった結果、これが発生しました。

何かがRulesetによって生き続けているクレイジーな巨大な割り当てを引き起こしています。

[編集]
3.9にダウングレードし、そこからヒープ割り当てタイムラインを取得しています。 根本的に違うものを見つけたかどうかを見に行きます。

@ matthew-ディーン
あなたへのヒントを見つけました。

3.11では、RuleSetにリストされているリテーナの1つはImportManagerです。
3.9では、これは_そうではありません_。

ImportManagerによってすべてが存続し、ImportManagerがコンパイルプロセス全体でシングルトンである場合。 はい、そうです; ガベージコレクションができないため、メモリ使用量が大幅に増加します。 中間のルールセットすらありません。

@rjgottenうーん......オブジェクトに別のオブジェクトへの参照がある場合、なぜそれがGCを妨げるのでしょうか？ つまり、技術的には、すべてのオブジェクトがプロトタイプチェーンを介してパブリックAPIノードへの参照を保持します。 逆が真の場合、つまり、すべてのルールセットインスタンスへの参照を保持しているオブジェクトがある場合にのみ、GCが防止されます。

あなたは誤解しているようです。

「AがBの保持者である」とは、AがBへの参照を保持しているため、Bのガベージコレクションが妨げられていることを意味します。 したがって、ImportManagerがRulesetの保持者としてリストされていると書いたとき、私はあなたが結論したことを正確に表現しました。ImportManagerはRulesetインスタンスへの参照を保持し、それらのRulesetインスタンスのGCを防ぎます。

@rjgottenああ、そうですか？ その変化がどのようにしてそこにもたらされたのだろうか。 私が責任を負う可能性が高いか、それを行ったES6リファクタリングについて何かがあります。 しかし、ええ、それは間違いなくそれを行うことができます！ 調査していただきありがとうございます。

さて、この急進的なアイデアはどうですか。

ES6変換以外のすべてをチェリーピッキングでブランチを作成しました。 これは単純なことではなく、これですべての作業が無駄になりますが、Babelified / Typescriptされたファイルが既存のネイティブJSを上回らない場合は、それだけの価値はありません。

gitの履歴をどのように調整するかはわかりませんが、ここにブランチがあります-> https://github.com/less/less.js/tree/release_v3.12.0-RC1。 コンバージョンの計算は大したことなので、このブランチは比較するための確かなベンチマークになると思います。

その変化がどのようにしてそこにもたらされたのだろうか。 私が責任を負う可能性が高いか、それを行ったES6リファクタリングについて何かがあります。 しかし、ええ、それは間違いなくそれを行うことができます！ 調査していただきありがとうございます。

それは確かに奇妙です。 私が解読できたものから、ImportManagerは、ES6変換によって追加されたgluecode / polyfillを介して、どういうわけかルールセットのリテーナーになってしまうようです。

途中で終わりを迎える解決策はここにあるのだろうか。 つまり、Node.jsのES6ビルドを保持しますが、トランスパイルされたブラウザーターゲットもあります。 ES6変換によって追加されるコードの明確さを排除することは大きな損失になります。 😢

@rjgotten

ES6変換によって追加されるコードの明確さを排除することは大きな損失になります。

2つの理由から、見た目ほど悪くはないかもしれません。

1. ロールアップ構成はまだ存在しており、誰かがそれを調査したい場合はコミットからプルすることができます。
2. 私はしばらくの間、TypeScriptベースのLess4.0に積極的に取り組んできました。 このパフォーマンスの低下を追跡するよりも、それに時間を費やしたいと思います。 これはゼロからのリファクタリングであるため、決して近いものではありませんが、TSの性質上、参照を保持してGCを妨げるこれらの1回限りのオブジェクトミューテーションが発生する可能性はほとんどありません。 そして、コードは従うべきはるかに明確です。 だからそれがあります。

この問題を修正するためだけにすべてをES5にロールバックするのは大変な作業のようですが、書き直しが進行中であることを考えると理解できます。 それでも、この決定をどのくらいの期間生きなければならないかを検討する必要があります。 @rjgottenが述べたように、コードの明確さが。v4がまだ遠い場合は、ES5核オプションを選択する前に、特にこの問題以降、もう少し調査してみましょう。悪いもの）ほとんどのユーザーにとって、大したことではないようです。

これを経験して、コードを喜んで共有してくれる人はいますか？ 実際のプロジェクトを使用してベンチマークを実行し、変更が役立つかどうかを確認できれば素晴らしいと思います。 それが得られれば、ボトルネックが発生する可能性のある場所を絞り込んでみてください。

@ matthew-deanは、補足として、ルーズモードでBabelをコンパイルして、見栄えのするコードが生成されるかどうかを確認しましたか？

@seanCodes誰かがロールアップ/賛成です。 部分的には、元のコードを見て、出力と比較し、手がかりを探すことです。

私が持っている推測の1つは、一部の破壊ロジックにはオブジェクト作成の定型文がたくさんあるということです。

基本的に、誰かがこの問題を所有するために志願する必要があります。

@ matthew-deanは、補足として、ルーズモードでBabelをコンパイルして、見栄えのするコードが生成されるかどうかを確認しましたか？

@seanCodesコードは、BabelではなくTypeScriptを使用してコンパイルされます。 私の考えは、タイプチェックを強化するためにJSDocタイプを徐々に追加することでしたが、v4のTSは書き直しで十分であり、それが必要かどうかはわかりません。 したがって、誰かがBabelv。TypeScript（およびそれぞれに異なる設定）を試して、Babelがよりパフォーマンスの高いコードを生成するかどうかを確認できます。 Node.js用の非ES5ビルドを最初に作成したことが原因で発生したこの問題に注意してください： //github.com/less/less.js/issues/3414

@seanCodesまた、パフォーマンスの違いを確認するのはまだ難しいと感じています。 パフォーマンスの違いを明確に証明するためのPR /ステップを作成した人は誰もいません。 このスレッドには多くの逸話がありますが、再現可能なコードや手順がなければ、誰かがこれをどのように調査するのかわかりません。 理想的には、プロファイリングツールを起動して（Chromeデバッガーなどを介して）システムに数値を出力し、多数のテストを平均化するPRがあります。 ですから、これまでのところ、これは100％再現可能ではないので、誰もが再現ステップを提供できる限り、それが私が個人的にそのウサギの穴を降りたくなかった理由の一部です。 （つまり、「Chromeデバッガーを使用しました」のフィードバックは、一連の再現手順ではありません。知っておくと便利ですが、誰かが調査するのに役立ちません。追跡対象とその理由/結果を知る必要があります。期待される。）

したがって、現在のコードベースを使用してパフォーマンスの低下を改善したい場合は、おそらく複数のボランティアと1人の人がこの問題を所有する必要があります。

個人的には、_speed_のようにパフォーマンスの違いはあまり見られませんが、メモリ消費量の違いは驚くべきものであり、インポートの量と相関しているようです。これは、大まかなヒープ分析でも問題に関連しているようです。

それが正しければ、違いを確認するために、それぞれにいくつかのルールセットが含まれているインポートされたファイルが多数含まれている限り、実行可能なテストプロジェクトを誰でもジェリーリグできるはずです。

@rjgotten

それが正しければ、インポートされたファイルがたくさんあり、それぞれにいくつかのルールセットが含まれているテストプロジェクトをジェリーリグして、違いを確認できるはずです。

ここで重要なのは「あなた」です。 😉

ここで重要なのは「あなた」です。 😉

不幸な言葉の選択。 つまり、一般的な意味で、つまり「誰でも」ということです。
自分でさらに掘り下げていきますが、現在、皿回しが多すぎます。

@rjgotten 「大量のインポートされたファイル」が何であるかについてのより良いアイデアを教えてください。 100個の別々のファイルがそれを行うのでしょうか、それとも1000個の話をしているのでしょうか？

また、どのようにして最初に問題に気づきましたか？ メモリ消費が原因でビルドが失敗しましたか、それともメモリ使用量を調べていましたか？ または、マシンの速度が低下していることに気づきましたか？

私はまだこれを複製しようとはしていませんが、推測と確認に頼る必要がないように、正確に何を探すべきかを学びたいと思っています。

100かそこらがそれをします。 これは、私が問題に気付いた実際のプロジェクトのサイズとほぼ同じです。

コーポレートCI環境で実行されているビルドが失敗し始めたときに最初に気づきました。 これらは、メモリ制限が構成されたDockerコンテナー内で実行されます。

@rjgotten 3.11.3でもまだメモリの問題がありますか？ 以前のリリースでインポート内のASTのキャッシュ（参照）を削除したので、インポートが保持されていて、ASTツリーがその中に保持されていた場合、メモリ使用量が増加しますが、ツリーを保持から外すと、それはそれを解決しますか？

@ matthew-deanはい、この問題は3.11.3でも引き続き発生します。

概念実証を作成しようとしますが、私は自分のプレートにたくさんあります。 時間があれば、これをやることリストに載せました。

@ matthew-dean以前は失敗していた、比較的大きなプロジェクトでこれをテストしたいと思います。 私が知る必要があることは何ですか？ このブランチ、 https：//github.com/less/less.js/tree/release_v3.12.0-RC1を使用する必要があり

@nfq試してみることができますが、このスレッドで広く

ちなみに、コンパイル中にlessオブジェクトを調べて永続オブジェクトを見つけようとしましたが、見つかりませんでした。 🤷‍♂️

パフォーマンスの問題も発生しています。 同じテストスイートの場合：

| バージョン| 時間|
| -| -|
| v3.9.0 | 〜1.6秒|
| v3.10.0〜v3.11.1 | 〜3.6秒|
| v3.11.2 + | 〜12秒|

ここで説明した3.9.0→3.10.0とは別に、 v3.11.2ではパフォーマンスが大幅に低下しているようです。 変更ログのこの変更は疑わしいようです。

3498インポートマネージャーのツリーキャッシュを削除します（＃3498）

わたしも。

同一のビルドのタイミング（すべてノード10.19.0）：

• v3.9：29.9秒
• v3.10：76.0秒
• v3.12：89.3秒

@ jrnail23

それらの結果を示すことができるレポはありますか？

@ matthew-dean https://github.com/less/less.js/issues/3434#issuecomment -672580467用に1つありhttps ：

申し訳ありませんが、@ matthew-dean、私はしません。 それらの結果は私の雇用主の製品からのものです。

それらの結果は私の雇用主の製品からのものです。

私もファイルを提供できないのと同じ理由です。 😞

@rjgotten @ jrnail23 @Justineo -興味があるだけ、あなたは同じインポートは別のファイルに複数回インポートされたケースの数を持っていますか？

私の場合、 @importステートメントを

@ matthew-dean、一般的なもの（たとえば、色変数、タイポグラフィなど）をインポートするbase.lessファイルがあります。
私たちのアプリのいくつかの簡単なgrepingは、 base.less参照（つまり、 <strong i="8">@import</strong> (reference) "../../../less/base.less"; ）が66の他のコンポーネント/機能固有のlessファイルによってインポートされることを示しています。また、他のコンポーネント/機能固有の少ないファイルをインポートします（それ自体がbase.less参照する場合があります）。
興味深いことに、（おそらく偶然に？）参照として自分自身をインポートする別のlessファイルもあるようです。

@rjgotten @ jrnail23 @Justineo -興味があるだけ、あなたは同じインポートは別のファイルに複数回インポートされたケースの数を持っていますか？

私にとって、それは「はい」です。 私が最初に問題を経験したプロジェクトは、他のすべてに含まれている一元化された変数ファイルを利用するスキナブルソリューションです。 さらに、コンポーネントベースのデザインを使用しており、特定の種類のボタンやフォントアイコンなどを生成するミックスインファクトリがあり、それらの一部もいくつかのファイルにインポートされます。

基本的; すべての依存関係は、その依存関係を厳密にインポートするように設定されており、インポートを重複排除して正しい順序に並べ、正しいCSS出力を確保するためにLessコンパイラに依存しています。

@rjgotten

私はそれを投稿して削除しました（私はそれを理解したと思ったのですが、それでも複製できませんでした）、どのプロセスを含め、人々が報告しているものを再現する手順はまだありません。

これと同じくらい単純なものでさえ：

3.11では、RuleSetにリストされているリテーナの1つはImportManagerです。

その証拠は見つかりませんが、どうやってそれを決定できたのかもわかりません。 私はChromeDevToolsに精通していないので、何が何によって保持されているかなどを判断する方法を知ることができません。これは、Googleが私を助けてくれなかった漠然としたトピックです。 同様に、人々はノードプロセスに接続していますか？ ブラウザで実行してブレークポイントを設定しますか？ 手順は何ですか？

つまり、この号が発行された年には、どのレポートにも再現する手順がありません。 これらの逸話はすべて何かを意味していると思いますが、見つけたものをどのように判断しましたか？ それとも、これを実証するセットアップを考えることができますか？ 私はそれを理解するのを手伝いたいのですが、それを再現する方法がわかりません。

@Justineoリポジトリで、メモリサイズまたはコンパイル時間を決定するためにどのような手順を実行しましたか？ 何を使って測定しましたか？

@Justineoキャッシュの削除を指摘したので（これはおそらく悪い考えでした）、このブランチをテストして、ビルド速度に役立つかどうかを確認できますか？ https://github.com/less/less.js/tree/cache-restored

今日の実験/テストに関する最新情報を提供するためだけに：

グラントのshell:test回

• 3.9未満-1.8秒
• 少ない3.12（Babel-ES5にトランスパイル）-9.2秒
• 少ない3.12（Babel-ES6にトランスパイル）-3.1s
• 少ない3.12（TypeScript-ES5にトランスパイル）-3.2s

ですから、長短は、トランスパイルされたコードは常に遅いということだと思います。私たちはそれ以外のことを考えるのは素朴でした。 JavaScriptの世界では、トランスパイルが非常に「標準」になっているので、ちょっと驚いています。 これを裏付ける他の研究はありますか？

@Justineoリポジトリで、メモリサイズまたはコンパイル時間を決定するためにどのような手順を実行しましたか？ 何を使って測定しましたか？

npm run testは、経過した合計時間を生成します。 また、他のプロジェクトでは、3.12に切り替えるとOOMが発生します。

TypeScriptで生成されたコードを見ると、次のようになります。

Object.defineProperty(exports, "__esModule", { value: true });
var tslib_1 = require("tslib");
var node_1 = tslib_1.__importDefault(require("./node"));
var variable_1 = tslib_1.__importDefault(require("./variable"));
var property_1 = tslib_1.__importDefault(require("./property"));
var Quoted = /** <strong i="6">@class</strong> */ (function (_super) {
    tslib_1.__extends(Quoted, _super);
    function Quoted(str, content, escaped, index, currentFileInfo) {
        var _this = _super.call(this) || this;
        _this.escaped = (escaped == null) ? true : escaped;
        _this.value = content || '';
        _this.quote = str.charAt(0);
        _this._index = index;
        _this._fileInfo = currentFileInfo;
        _this.variableRegex = /@\{([\w-]+)\}/g;
        _this.propRegex = /\$\{([\w-]+)\}/g;
        _this.allowRoot = escaped;
        return _this;
    }

対：

var Node = require('./node'),
    Variable = require('./variable'),
    Property = require('./property');

var Quoted = function (str, content, escaped, index, currentFileInfo) {
    this.escaped = (escaped == null) ? true : escaped;
    this.value = content || '';
    this.quote = str.charAt(0);
    this._index = index;
    this._fileInfo = currentFileInfo;
    this.variableRegex = /@\{([\w-]+)\}/g;
    this.propRegex = /\$\{([\w-]+)\}/g;
};

だから私の推測では、これらの余分な関数の定義と呼び出しはすべて、時間の経過とともに合計されますか？ これが赤いニシンでない限り、しかし私はこれが転生を除いて他に何に帰するべきかわかりません。 私が理解していないのは、TSがオリジナルに近いコードを生成できない理由です。

アップデート：

3.9テストを3.12と同等にしようとすると、基本的に1.2秒対1.3秒になります。 テストが変更されたため、この違いについてはもうわかりません。 まったく同じ少ないファイルに対して実行する必要があります。

@Justineo @rjgottenより効率的なビルドを作成するために、TypeScriptの微調整をいくつかプッシュしました。 そのブランチを構築して試してみませんか？ https://github.com/less/less.js/tree/cache-restored

@matthew-dean👍ありがとう！ 今日は後で試してみます。

cache-restoredブランチをテストしましたが、v3.11.2 +よりもはるかに高速で、v.3.1.0〜3.11.1とほぼ同じ速度です。

@Justineo

キャッシュで復元されたブランチをテストしましたが、v3.11.2 +よりもはるかに高速で、v.3.1.0〜3.11.1とほぼ同じ速度です。

まあ、それは有望です。 レッツは、このスレッドではいくつかの@rjgotten @ jrnail23からのフィードバックなどを取得します。 そのキャッシュの削除は、このスレッドが投稿された後でした（3.11.2）。 実際、これはメモリオーバーヘッドの一部を削除する試みでしたが、同じファイルを数回インポートする場合は、間違いなく事態を悪化させる可能性があります。

したがって、要するに、元の問題またはその原因（コード変換で発生した何かを除く）についてはまだわかりません。このブランチにまだこれらの問題があるかどうかを知りたいのですが、前に述べたように、明確な再現手順がないため、よくわかりません。

@ matthew-dean、 cache-restoredブランチを使おうとすると少し問題が発生します（ npm linkが失敗するため、ローカルで使用するために何をする必要があるのか​​よくわかりません自分）。
私が試すことができるカナリア/プレリリースバージョンを公開できますか？

@ jrnail23

これはうまくいったと思います。 Lessを削除し、 npm i [email protected]+84d40222インストールしてみてください

@ matthew-ディーン、私はちょうどそのバージョンを試しました、そしてそれは私にとってまだ悪いです。
新しいwebpackビルド（キャッシュなし）の場合、v3.9では62.4秒かかりますが、v3.13.1では121秒かかります。
キャッシュされたビルドの場合、v3.9には30秒かかり、v3.13.1には83〜87秒かかります。

@ jrnail23すべてのノードモジュールを削除して、 [email protected]+b2049010をインストールしてみてください。

3.9ベンチマーク未満：

4.0.1-alpha.0未満：

少ない4.0.1-alpha.2：

@Justineo @rjgottenこれも試してみませんか？

@ jrnail23 @Justineo @rjgotten

これは4.0ビルドであるため、コードに次のような重大な変更が加えられた場合にエラーが発生する可能性があることに注意してください。

• ミックスイン呼び出しには括弧が必要です（例： .mixin;は許可されていません）
• Lessのデフォルトの数学モードは括弧分割になっているため、スラッシュ（数学として意図されている）は括弧で囲む必要があります

そのため、私は今でははるかに楽観的ですが、最新のベンチマークに基づいて問題を修正しましたが、なぜこの問題が発生しているのかまだわかりません。 他のすべての人のパフォーマンスが維持されている場合は、最終的に問題を絞り込んだ方法と見つけたものの概要を説明できます。 言い換えれば、問題がどこにあるか、またはあったかを見つけたと思いますが、必ずしも理由ではありません。

https://github.com/less/less.js/issues/3434#issuecomment -672580467と同じテストスイートの結果：

| バージョン| 時間|
| -| -|
| v3.9.0 | 〜1.6秒|
| v3.10.0〜v3.11.1 | 〜3.6秒|
| v3.11.2 + | 〜12秒|
| 4.0.1-alpha.2 + b2049010 | 〜1.6秒|

特定のテストスイートでは、パフォーマンスレベルがv3.9.0と同じくらい速く改善されたことを確認できます。 マットに感謝します！ 数学モードでのブレークの変更についてはよくわかりませんが。 これを変更すると、多くのアプリケーションが破損する可能性があるため、パフォーマンスの問題が解決されたとしても、v3.9.0でスタックする可能性があります。

@Justineo

数学モードでのブレークの変更についてはよくわかりませんが。

math=alwaysモードで明示的にコンパイルして、以前の数学の動作を取得できます。 これは単に異なるデフォルトです。

問題の内訳

TL; DR-クラスパターンに注意してください

問題は、BabelとTypeScriptの両方のクラスの変換にありました。 （言い換えれば、両方ともトランスパイルされたコードで同じパフォーマンスの問題があり、Babelはわずかに悪化していました。）さて、数年前、クラスパターンが導入されたとき、私はそのクラスを教えられました-そしてこの問題まで信じられていました- JavaScriptの継承は、機能継承の構文糖衣です。

要するに、そうではありません。 _（編集：まあ....そうです、そうではありません。それは、「継承」が何を意味するか、そしてすぐにわかるようにそれをどのように定義したかによって異なります。 JavaScriptのプロトタイプチェーンに「継承」を作成し、クラスは1つのパターンのみを表しますが、そのパターンは他のすべてのパターンとは多少異なるため、TS / Babelは、特殊な関数を使用してこのパターンを「模倣」するヘルパーコードを必要としています。）_

少ないコードは次のようになりました：

var Node = function() {
  this.foo = 'bar';
}

var Inherited = function() {
  this.value = 1;
}
Inherited.prototype = new Node();

var myNode = new Inherited();

ここで、「最新の」JSを使用してこれを書き直したいとします。 実際、私が行ったこのプロセスを自動化することはできますが、どちらの方法でも同じように記述できます。

class Node {
  constructor() {
    this.foo = 'bar';
  }
}
class Inherited extends Node {
  constructor() {
    super();
    this.value = 1;
  }
}
var myNode = new Inherited();

同じことですよね？ 実は違う。 1つ目は、プロパティが{ value: 1 }オブジェクトを作成し、そのプロトタイプチェーンには、 { foo: 'bar' }オブジェクトがあります。

2つ目は、 InheritedとNode両方でコンストラクターを呼び出すため、 { value: 1, foo: 'bar' }ような構造を持つオブジェクトを作成します。

さて、_user_の場合、どちらの場合もmyNodeからvalueとfoo両方にアクセスできるため、これは実際には問題ではありません。 _機能的に_、それらは同じように動作するように見えます。

ここに私は純粋な憶測を入力します

V8のようなJITエンジンに関する記事で私が覚えていることから、オブジェクト構造は実際には非常に重要です。 { value: 1 } 、 { value: 2 } 、 { value: 3 } 、 { value: 4 }ような構造の束を作成すると、V8はその構造の内部静的表現を作成します。 基本的に、構造とデータを1回保存し、次にデータをさらに3回保存します。

しかし、これに毎回異なるプロパティを追加すると、 { a: 'a', value: 1 } 、 { b: 'b', value: 2 } 、 { c: 'c', value: 3 } 、 { d: 'd', value: 4 }になり、これらは4つのデータセットを持つ4つの異なる構造になります。 、元のクラスの同じセットから作成された場合でも。 JSオブジェクトのすべてのミューテーションは、データルックアップを最適化解除し、関数にトランスパイルされるクラスパターンは、（おそらく）よりユニークなミューテーションを引き起こします。 （これがブラウザーでのネイティブクラスのサポートに当てはまるかどうかは正直わかりません。）

AFAIK、また真実は、オブジェクトにあるプロパティが多いほど、個々のプロパティのルックアップにかかる時間が長くなるということです。

エンドユーザーにとっても、JSエンジンは非常に高速であるため、これが問題になることはめったにありません。 Buuuuutは、多くのオブジェクトのプロパティ/メソッドをできるだけ早く作成および検索するエンジンを維持していると言います。 （Ding ding ding。）TypeScript / Babelがオブジェクトを「拡張」する方法と、ネイティブの機能的なプロトタイプの継承との間のこれらの小さな違いは、突然、非常に急速に増加します。

古いLess構文とTSでトランスパイルされたクラスパターンを使用して、ノードと継承関数の最低限の実装を作成しました。 ゲートのすぐ外では、継承されたノードは25％多くのメモリ/リソースを消費します。これは、継承されたノードのインスタンスが作成される前です。

ここで、一部のノードが他のノードから継承していると考えてください。 つまり、継承されたインスタンスと同様に、クラスのメモリ内表現が増加し始めます。

繰り返しますが、これは推測です

クラスへの変換がパフォーマンスにとってこれほど悲惨なことだと聞いたことがないので、私はこれらすべてを一粒の塩でとることを強調しなければなりません。 私が_考えている_のは、Lessが使用しているオブジェクト/インスタンスルックアップの特別な組み合わせがあり、JITを大幅に最適化していないということです。 _（この場合、トランスパイルされたクラスのパフォーマンスがネイティブJS継承メソッドよりもはるかに悪い理由をJavaScriptエンジンの専門家が知っている場合は、知りたいと思います。）_両方のメソッドを使用して、何千もの継承オブジェクトを作成するパフォーマンス測定値を作成しようとしました。パフォーマンスに一貫した違いは見られませんでした。

したがって、「JavaScriptのクラスが悪い」と言う前に、このパフォーマンスの低下を引き起こしたのは、トランスパイルされたクラスとネイティブJSの違いと相まって、Lessコードベースの他の本当に不幸なパターンである可能性があります。

私が最終的にそれを理解した方法

正直なところ、私はクラスのパターンを疑ったことはありません。 元のES5コードが逆バベリファイドコードよりも高速に実行されることは知っていましたが、矢印関数の周りに何かがあるか、構文がどこかに広がっているのではないかと疑っていました。 私はまだ最新のES5ブランチを持っていたので、ある日、 lebab再度実行し、次の変換のみを使用することにしました： let,class,commonjs,template 。 その時、私はそれが再びパフォーマンスの問題を抱えていることを発見しました。 文字列テンプレートやlet-to-varではないことはわかっていました。 輸入が必要なのかもしれないと思ったので、しばらく遊んでみました。 それはクラスを残しました。 そのため、思い切って、すべての拡張クラスを機能継承に書き直しました。 バム、パフォーマンスが戻ってきました。

訓話

そう！ 学んだ教訓。 プロジェクトが古いES5コード上にあり、その「モダンな」Babel化またはTypeScriptedの良さを切望している場合は、何をトランスパイルしても、記述しなかったことを忘れないでください。

少し保守しやすいパターンで、

math = alwaysモードで明示的にコンパイルして、以前の数学の動作を取得できます。 これは単に異なるデフォルトです。

私はこれを知っています。 多くの異なるチームにまたがるLessコードベースが多数あるため、デフォルトのコンパイルオプションでも変更を中断すると、通信コストが増加します。 メリットが壊れる価値があるかどうかはわかりません。

詳細な内訳をありがとう！

コンパイルされた出力でObject.assignの使用法を見ました。これは、ポリフィルが必要にならない限り、ネイティブES class構文をサポートするブラウザーでのみ機能することを意味します。 それで、古い環境（IE11、ノード4など）のサポートを終了する場合は、ES5にトランスパイルせずにネイティブ構文を使用できますか？

同時に、パフォーマンスの低下の修正と重大な変更を分離できるとよいと思います。つまり、パフォーマンスの修正をv3に配置し、重大な変更をv4にのみ含めることを意味します。

@ matthew-ディーン
ESクラスが犯人であるという事実は怖いクレイジーです。
入念な内訳をありがとう。

表示されます：_継承よりも構成_😛

参考までに; よりクリーンな典型的な継承チェーンが必要な場合は、実際には例とは少し異なる方法で行う必要があります。
このようにObject.createを使用する場合：

var Node = function() {
  this.foo = 'bar';
}
Node.prototype = Object.create();
Node.prototype.constructor = Node;

var Inherited = function() {
  Node.prototype.constructor.call( this );
  this.value = 1;
}
Inherited.prototype = Object.create( Node.prototype );
Inherited.prototype.constructor = Inherited;

var myNode = new Inherited();

次に、プロパティをインスタンス自体にフラット化し、インスタンス自体が同じ形状を共有します。 プロトタイプは形を共有します。 _そして_プロパティアクセスごとにプロトタイプチェーンをクロールする必要がなくなります。 😉

@Justineo

コンパイルされた出力でObject.assignの使用法を見ました。つまり、ポリフィルが必要にならない限り、ネイティブESクラス構文をサポートするブラウザーでのみ機能します。 それで、古い環境（IE11、ノード4など）のサポートを終了する場合は、ES5にトランスパイルせずにネイティブ構文を使用できますか？

私はそれが完全に正しいとは思いません。つまり、Object.assignはクラスの実装の直前に着陸しましたが、あなたの主張は理解されています。 [Something].prototype.property何度も書くのを避けたいと思っていました：/

技術的には、すべてがまだトランスパイルしているので、わかりません。 当初の目標は、より保守可能で読みやすいコードベースでした。 一部の環境でObject.assignポリフィルが必要な場合は、そうしてください。 それは、Lessがサポートしていないバージョンのものになります。

同時に、パフォーマンスの低下の修正と重大な変更を分離できるとよいと思います。つまり、パフォーマンスの修正をv3に配置し、重大な変更をv4にのみ含めることを意味します。

私はそれを考えてきました、そしてそれもまた公正な点だと思います。 Lessの3つのメジャーバージョンの構築/維持を頭が爆発しないようにしようとしています。

@rjgotten AFAIKは、定義したとおりに、クラスパターンが実行することになっていることです。 重大な違いが見られない場合を除きます。 だから🤷‍♂️。 パフォーマンスが良好な場合は、Lessのノード継承パターンを再度変更するつもりはありません（ @Justineoが提案したようにこのObject.assign呼び出しを削除する場合を除きます）。

@Justineo @rjgottenこれを試すことができますか： [email protected]+b1390a54

試してみました：

| バージョン| 時間|
| -| -|
| v3.9.0 | 〜1.6秒|
| v3.10.0〜v3.11.1 | 〜3.6秒|
| v3.11.2 + | 〜12秒|
| 4.0.1-alpha.2 + b2049010 | 〜1.6秒|
| 3.13.0-alpha.10 + b1390a54 | 〜4.7秒|

追伸 Node.jsv12.13.1でテスト済み。

私は何ですか。

個別のベンチマークを設定する時間がありませんでした。
しかし、統合テストの観点から、ここにいくつかの実際の数値があります。Lessを使用する実稼働グレードのWebpackプロジェクトの累積結果です。

バージョン| 時間| ピークメモリ
：------------------------ | --------：| ------------：
3.9 | 35376ms | 950MB
3.11.3 | 37878ms | 920MB
3.13.0-alpha.10 + b1390a54 | 34801ms | 740MB
3.13.1-alpha.1 + 84d40222 | 37367ms | 990MB
4.0.1-alpha.2 + b2049010 | 35857ms | 770MB

私にとって、3.13.0は_最高の_結果をもたらします...🙈

3.11.3はまた、3.11.1バージョンで以前に見たような暴走メモリの使用がないようです。
しかし、4.0.1と3.13.0のベータ版はさらに優れています。

キャッシュを復元した3.13.1は、実際のコンパイル時間を改善するのに役立たず、メモリ使用量を増やすだけです。

@rjgottenええ、問題は、このスレッドでは、人々がさまざまなものを測定しており、これまでのところ、誰もが本質的に複製できないプライベートデータを持っていることだと思います（Lessベンチマークに提出するか、PRに変換する必要があります）。 Lessにはベンチマークテストがあります。これは、リポジトリのさまざまなクローンに対して使用して、解析/評価時間の違いを自分で確認できますが、キャッシュは（現在）適用されません。

これは、ツリーの継承が変更され、解析ツリーのキャッシュが復元された公開ビルドです。 [email protected]+e8d05c61

テストケース

https://github.com/ecomfe/dls-tooling/tree/master/packages/less-plugin-dls

結果

| バージョン| 時間|
| -| -|
| v3.9.0 | 〜1.6秒|
| v3.10.0〜v3.11.1 | 〜3.6秒|
| v3.11.2 + | 〜12秒|
| 4.0.1-alpha.2 | 〜1.6秒|
| 3.13.0-alpha.10 | 〜4.7秒|
| 3.13.0-alpha.12 | 〜1.6秒|

Node.jsバージョン

v12.13.1

私には、このバージョンは完全に機能しているようです。 同僚に試して確認してもらいます。

私にとってはalpha.10よりも少し悪い動作をしますが、変動する可能性もあります。

バージョン| 時間| ピークメモリ
：------------------------ | --------：| ------------：
3.9 | 35376ms | 950MB
3.11.3 | 37878ms | 920MB
3.13.0-alpha.10 + b1390a54 | 34801ms | 740MB
3.13.0-alpha.12 + e8d05c61 | 36263ms | 760MB
3.13.1-alpha.1 + 84d40222 | 37367ms | 990MB
4.0.1-alpha.2 + b2049010 | 35857ms | 770MB

@ matthew-dean、私のコードはまだ4.0.1-alpha.2+b2049010変更と互換性がないようです。 問題を解決して試してみることができるかどうかを確認します。

@rjgottenええ、テストケースの違いはわずかなようです。

この結果、3.xと4.0の両方のリリースを準備できると思います。 この問題が解決されていない状態で4.0をプッシュすることを望んでいませんでした。 ありがたいことに、それはそうであったように見えます。

私が行うもう1つの項目は、特定のベンチマークしきい値を下回った場合に失敗するCIパイプラインを配置することです。

@ jrnail23 4.0 alphaを実行するように変更できれば素晴らしいのですが、それまでの間、 [email protected]+e8d05c61試してみてください。

@ matthew-dean、ビルドで次の情報を取得しています。

• v3.9：98秒
• v3.10.3：161秒
• v3.13.0-alpha.12：93-96秒

だから、あなたはあなたがなりたい場所に戻っているように見えます！ よくやった！

よくやった！

ええ、私は2番目に行きます。 三番目; そして4番目。
これは厄介で厄介なパフォーマンスの低下であり、クリーンアップするのに本当に多くの労力を要しました。

仕事は_非常によく_完了しました。

大丈夫チーム！ 3.xビルドを公開し、しばらくしてから、おそらく来週、4.0を公開します。 両方ともパフォーマンスが修正されているはずです。 デバッグを手伝ってくれたすべての人に感謝します！

ちなみに、私は現在、Less.jsコードベースをTypeScriptに変換している最中であり、この機会を利用してパフォーマンスの調整/リファクタリングを行う予定です。 興味のある方はいつでもお手伝いさせていただきます！ https://github.com/matthew-dean/less.js/compare/master...matthew-dean：next

あなたがいくつかの余分な目を好む特定の何か？ PRがとても大きいのでどこから始めたらいいのかわからない

@kevinramharakそれは公正な質問です。 正直なところ、TypeScriptへの変換で予期しない障害（解決が困難になったエラー）に遭遇し、今ではそれを行うことをまったく考え直しています。 現状ではLessは正常に動作しており、（リファクタリング/新しい言語機能の追加を容易にするために）変換したかった多くの理由は、新しい言語機能のアイデアを新しいpre-に移動することにしたため、今では無関係です。処理言語。 自己宣伝したくないので、詳細が必要な場合はTwitterまたはGitterでDMを送ってください。