Ja. Ich habe vor ein paar Wochen auch das Standard-Automl-Stoppkriterium in max_batches=1 geändert, was nicht geholfen hat.

Die von dir aufgeführten Lösungen gefallen mir! Außerdem noch eines von mir:

1. Fügen Sie im Notebook versteckten Code hinzu, der lange laufende Berechnungen überspringen würde. Dies könnte Code sein, der die Pipeline-Anpassung/Vorhersage verspottet. Vorteil: funktioniert. Nachteil: Stimmt möglicherweise nicht mit dem überein, was Benutzer erhalten, wenn sie von Hand ausgeführt werden, und versteckter Code ist verwirrend.
2. Führen Sie bei Notebooks mit langer Laufzeit einmal lokal vor und speichern Sie die Ausgabe im Notebook. Nbsphinx verwendet eine gespeicherte Ausführung, wenn eine vorhanden ist, anstatt sie erneut auszuführen. Vorteil: funktioniert. Nachteil: Wir können vergessen, die Ausgabe regelmäßig zu aktualisieren.
3. Vereinfachen/löschen Sie einen Teil des Notizbuchinhalts. Ziehen Sie beispielsweise in Betracht, die Datengröße, das Stoppkriterium usw. nach Möglichkeit zu verringern. Vorteil: Beschleunigungen. Nachteil: Einige Beispiele wie Text können nicht vollständig ausgegeben werden.

Ich empfehle, Option 2 zu wählen, aber mit Option 3 im Hinterkopf.

1627 wurde als Duplikat geschlossen, aber ich denke, es könnte immer noch etwas geben, das in dieser Ausgabe nicht behandelt wurde, also hier posten:

Mir ist aufgefallen, dass die Erstellung von Dokumenten viel länger dauert. Ich denke, dies liegt wahrscheinlich daran, dass die automl-Dokumente in c871f3b geändert wurden, um den Betrugsdatensatz anstelle des Brustkrebsdatensatzes (+ an anderer Stelle?) zu verwenden, um infer_problem_types zu präsentieren, da der Brustkrebsdatensatz nur numerische Spalten hat.

Ich vermute, dies ist ein anderes Problem / Grund für die noch längere Build-Zeit von Dokumenten von den vorherigen 20 Minuten auf jetzt > 30 Minuten und könnte erwähnenswert sein!

@dsherry Zur Info

Eine andere mögliche Lösung besteht darin, mehrere Prozessoren zum Erstellen der Dokumente zu verwenden:

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

Update nach Diskussion mit @dsherry.

Durch das Hinzufügen des -j Flags zu unserem Makefile kann der build docs Test auf Circleci schneller abgeschlossen werden, wie hier zu sehen

So sieht ein erfolgreicher Build für ReadtheDocs aus, der etwas mehr als 20 Minuten in Anspruch nimmt. Die Unterschiede zwischen den HTML- und Latex-Build-Zeiten deuten darauf hin, dass das Erstellen der Jupyter-Notebooks selbst nicht viel Zeit in Anspruch nimmt, was gut ist.

Aber wir sind auch Fälle zu finden , wo der Bau wie nicht diese . Wir haben festgestellt, dass ReadtheDocs aus irgendeinem Grund die vollständige Befehlsfolge zweimal ausführt, was dazu führt, dass der Build viel länger dauert (jeweils weit über 30 Minuten zum Erstellen der HTML- und Latex-Dateien) und der Doc-Build fehlschlägt. Ich werde mich mit dem ReadtheDocs-Supportteam in Verbindung setzen, um herauszufinden, warum dies geschieht und wie wir es beheben können, und ich werde diese Ergebnisse hier aktualisieren, wenn ich Feedback bekomme.

@bchen1116 hat den Support kontaktiert und sie sagten

Es sieht so aus, als ob die zugrunde liegende Ursache dieses Fehlers die Anzahl der aktiven Versionen ist, die Sie haben. Ich sehe einige Fehler in unseren Protokollen, die sich darauf beziehen.
Um dies vorerst zu umgehen, können Sie die Anzahl der aktiven Versionen reduzieren, die Sie behalten. Es sieht so aus, als ob Sie Versionen für einzelne Branches oder Pull-Requests erstellen. Haben Sie unsere Funktion zum Erstellen von Pull-Requests ausprobiert? Dies würde dazu beitragen, die nicht benötigten Versionen nach dem Erstellen zu entfernen, während der erstellte Inhalt weiterhin erhalten bleibt.

Ich glaube, die hier erwähnte "Pull-Request-Building-Funktion" ist dies und bestätigt.

Aktualisieren:
Wir haben RTD aktualisiert, um nur aus Pull-Requests zu bauen, und die unnötigen Builds in verschiedene Versionen (Zweige), die wir pushen, entfernt. Darüber hinaus haben wir alle unnötigen (nicht markierten) Versionen aus RTD (verschiedene Branches, die wir für PRs verwenden) gelöscht, was den Doc-Builds anscheinend geholfen hat. Wir bemerken keine Zeitüberschreitungen von Dokumenten bei Builds, daher werden wir dieses Problem morgen schließen, es sei denn, wir sehen wieder Zeitüberschreitungen.

@bchen1116 ist das jetzt schließbar?

Wird jetzt geschlossen, da es keine Probleme mit langsamen Doc-Builds gab.