Ouais. J'ai changé le critère d'arrêt automatique par défaut en max_batches=1 a quelques semaines également, ce qui n'a pas aidé.

J'aime les solutions que vous avez énumérées! Plus un des miens :

1. Ajoutez du code caché dans le bloc-notes qui éviterait les longs calculs. Cela pourrait être un code qui se moque de l'ajustement/de la prédiction du pipeline. Avantage : fonctionne. Inconvénient : peut ne pas correspondre à ce que les utilisateurs obtiennent lorsqu'ils exécutent à la main, et le code caché est déroutant.
2. Pour les blocs-notes de longue durée, effectuez une pré-exécution locale une fois et enregistrez la sortie dans le bloc-notes. Nbsphinx utilisera une exécution sauvegardée s'il en existe une au lieu de la réexécuter. Avantage : fonctionne. Inconvénient : on peut oublier de mettre à jour périodiquement la sortie.
3. Simplifiez/supprimez une partie du contenu du bloc-notes. Par exemple, envisagez de réduire la taille des données, le critère d'arrêt, etc. si possible. Avantage : les accélérations. Inconvénient : ne peut pas afficher la sortie complète pour certains exemples, comme le texte.

Je recommande que nous allions avec l'option 2, mais avec l'option 3 à l'esprit.

1627 a été fermé en tant que doublon, mais je pense qu'il pourrait encore y avoir quelque chose qui n'a pas été couvert dans ce numéro, alors postez ici :

J'ai remarqué que les documents prenaient beaucoup plus de temps à créer. Je pense que cela est probablement dû au fait que les documents automl ont été modifiés dans c871f3b pour utiliser l'ensemble de données sur la fraude, au lieu de l'ensemble de données sur le cancer du sein (+ ailleurs ?)

Je soupçonne qu'il s'agit d'un problème / raison différent du temps de construction encore plus long des documents, des 20 minutes précédentes à maintenant > 30 minutes, et cela pourrait valoir la peine d'être mentionné !

@dsherry Pour info

Une autre solution possible consiste à utiliser plusieurs processeurs pour créer les documents :

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

Mise à jour après discussion avec @dsherry.

L'ajout du drapeau -j à notre Makefile permet au test build docs sur circleci de se terminer plus rapidement, comme on le voit ici . Malheureusement, ReadtheDocs n'exécute pas cette commande, ce qui signifie que la génération réelle de la documentation publiée prend encore un certain temps et génère souvent des erreurs.

Voici à quoi ressemble une construction réussie pour ReadtheDocs, qui prend un peu plus de 20 minutes. Les différences entre les temps de construction HTML et Latex suggèrent que la construction des blocs-notes Jupyter eux-mêmes ne prend pas beaucoup de temps, ce qui est bien.

Cependant, nous trouvons également des cas où la construction échoue comme ceci . Nous avons remarqué que pour une raison quelconque, ReadtheDocs exécute la séquence complète de commandes deux fois, ce qui fait que la construction prend beaucoup plus de temps (plus de 30 minutes chacune pour créer les fichiers HTML et latex) et provoque l'échec de la construction du document. Je ferai un suivi avec l'équipe d'assistance ReadtheDocs pour voir pourquoi cela se produit et comment nous pouvons résoudre ce problème, et je mettrai à jour ces résultats ici lorsque j'aurai des commentaires.

@ bchen1116 a contacté le support et ils ont dit

Il semble que la cause sous-jacente de ce bogue soit le nombre de versions actives que vous possédez. Je vois quelques erreurs dans nos journaux à ce sujet.
Pour contourner ce problème pour l'instant, vous pouvez réduire le nombre de versions actives que vous conservez. Il semble que vous construisiez des versions pour des branches individuelles ou des demandes d'extraction, avez-vous essayé notre fonctionnalité de création de demande d'extraction ? Cela aiderait à supprimer les versions inutiles après la construction, tout en conservant le contenu construit.

Je crois que la "fonctionnalité de création de demande d'extraction" référencée ici est la suivante , confirmant.

Mettre à jour:
Nous avons mis à jour RTD pour générer uniquement à partir de demandes d'extraction, en supprimant les versions inutiles vers différentes versions (branches) que nous poussons. De plus, nous avons supprimé toutes les versions inutiles (non étiquetées) de RTD (branches diverses que nous utilisons pour les PR), ce qui semble avoir aidé la construction de la doc. Nous ne remarquons aucun délai d'expiration de la documentation sur les versions, nous fermerons donc ce problème demain à moins que nous ne recommencions à voir des délais d'expiration.

@bchen1116 est-il possible de fermer maintenant ?

Fermeture maintenant, car il n'y a eu aucun problème avec les versions lentes de la documentation.