Evalml: ドキュメントの作成には長い時間がかかります

作成日 2020年11月10日  ·  8コメント  ·  ソース: alteryx/evalml

最近の時点で、ドキュメントはcircle-ciでビルドするのに約14分かかりましたが、以前のリリースではビルドするのに約6分かかりました。 この速度低下の根本的な原因は、木工品がいくつかのカテゴリ変数をテキストとして推測しているため、AutoMLがTextFeaturizerを使用するようになっているようです。 ただし、wwがカテゴリとテキストの推論を修正したとしても、ドキュメントを作成するにつれて、ドキュメントを作成する時間が必然的に長くなります。 これにより、開発者がローカルでドキュメントを反復処理することが困難になります。

可能な解決策:

  • 長時間実行される計算をスキップするいくつかの隠しコードをノートブックに追加します。
  • nb-sphinxを使用するか、ドキュメントキャッシュの長時間実行される計算を読み取ります。
documentation testing

最も参考になるコメント

@dsherryとの次の議論を更新します。

-jフラグをMakefile追加すると、ここに示すように、circleciでのbuild docsテストをより速く終了できます。 残念ながら、ReadtheDocsはこのコマンドを実行しません。つまり、公開されたドキュメントの実際の生成にはまだ時間がかかり、エラーが発生することがよくあります。

これは、ReadtheDocsのビルドが成功した場合のように見え、完了するまでに20分強かかります。 HTMLとLaTeXのビルド時間の違いは、Jupyterノートブック自体のビルドにそれほど時間がかからないことを示しています。これは良いことです。

ただし、このようにビルドが失敗するインスタンスも見つかります。 何らかの理由で、ReadtheDocsがコマンドの完全なシーケンスを2回実行していることに気付きました。これにより、ビルドにはるかに長い時間がかかり(HTMLファイルとlatexファイルを作成するのにそれぞれ30分以上)、ドキュメントのビルドが失敗します。 ReadtheDocsサポートチームにフォローアップして、これが発生している理由と修正方法を確認します。フィードバックが得られたら、ここでそれらの結果を更新します。

全てのコメント8件

うん。 数週間前にも、デフォルトのautoml停止基準をmax_batches=1に変更しましたが、これは役に立ちませんでした。

私はあなたがリストした解決策が好きです! プラス私自身の1つ:

  1. 長時間実行される計算をスキップするいくつかの隠しコードをノートブックに追加します。 これは、パイプラインの適合/予測を模倣するコードである可能性があります。 利点:動作します。 短所:ユーザーが手動で実行したときに得られるものと一致しない可能性があり、さらに非表示のコードは混乱を招きます。
  2. 長時間実行されるノートブックの場合は、ローカルで1回事前実行し、出力をノートブックに保存します。 Nbsphinxは、再実行する代わりに、保存された実行が存在する場合はそれを使用します。 利点:動作します。 短所:出力を定期的に更新するのを忘れる可能性があります。
  3. ノートブックのコンテンツの一部を簡略化/削除します。 たとえば、可能であれば、データサイズを小さくしたり、基準を停止したりすることを検討してください。 利点:スピードアップ。 短所:テキストなどの一部の例では、完全な出力を表示できません。

オプション2を使用することをお勧めしますが、オプション3を念頭に置いてください。

1627は複製として閉鎖されましたが、この問題でカバーされていない何かがまだそこにある可能性があると思うので、ここに投稿してください:

ドキュメントの作成にかなり時間がかかっていることに気づきました。 これは、c871f3bでautomlドキュメントが変更され、乳がんデータセットに数値列しかないため、乳がんデータセット(+他の場所?)ではなく詐欺データセットを使用してinfer_problem_typesを表示したためと考えられます。

これは、以前の20分から現在の30分を超えるまで、ドキュメントのビルド時間がさらに長くなる別の問題/理由であると思われます。言及する価値があります。

@dsherry FYI

別の可能な解決策は、複数のプロセッサを使用してドキュメントを作成することです。

https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption -sphinx-build-j

@dsherryとの次の議論を更新します。

-jフラグをMakefile追加すると、ここに示すように、circleciでのbuild docsテストをより速く終了できます。 残念ながら、ReadtheDocsはこのコマンドを実行しません。つまり、公開されたドキュメントの実際の生成にはまだ時間がかかり、エラーが発生することがよくあります。

これは、ReadtheDocsのビルドが成功した場合のように見え、完了するまでに20分強かかります。 HTMLとLaTeXのビルド時間の違いは、Jupyterノートブック自体のビルドにそれほど時間がかからないことを示しています。これは良いことです。

ただし、このようにビルドが失敗するインスタンスも見つかります。 何らかの理由で、ReadtheDocsがコマンドの完全なシーケンスを2回実行していることに気付きました。これにより、ビルドにはるかに長い時間がかかり(HTMLファイルとlatexファイルを作成するのにそれぞれ30分以上)、ドキュメントのビルドが失敗します。 ReadtheDocsサポートチームにフォローアップして、これが発生している理由と修正方法を確認します。フィードバックが得られたら、ここでそれらの結果を更新します。

@ bchen1116がサポートに連絡し、彼らは言った

このバグの根本的な原因は、使用しているアクティブなバージョンの数にあるようです。 これに関連するログにいくつかのエラーがあります。
今のところこれを回避するには、保持するアクティブなバージョンの数を減らすことができます。 個々のブランチまたはプルリクエストのバージョンをビルドしているようですが、プルリクエストのビルド機能を試しましたか? これは、ビルドされたコンテンツを保持しながら、ビルド後に不要なバージョンを削除するのに役立ちます。

ここで参照している「プルリクエスト構築機能」はこれだと思います。

アップデート:
プルリクエストのみからビルドするようにRTDを更新し、プッシュするさまざまなバージョン(ブランチ)への不要なビルドを削除しました。 さらに、RTD(PRに使用するその他のブランチ)から不要な(タグなしの)バージョンをすべて削除しました。これは、ドキュメントの作成に役立ったようです。 ビルドでドキュメントがタイムアウトすることはありません。そのため、タイムアウトが再び表示されない限り、明日この問題をクローズします。

@ bchen1116これは今

遅いドキュメントビルドに問題はなかったので、ここで終了します。

このページは役に立ちましたか?
0 / 5 - 0 評価