हां। मैंने कुछ हफ़्ते पहले डिफ़ॉल्ट automl स्टॉपिंग मानदंड को max_batches=1 में भी बदल दिया, जिससे कोई फायदा नहीं हुआ।

मुझे आपके द्वारा सूचीबद्ध समाधान पसंद हैं! प्लस मेरा एक:

1. नोटबुक में कुछ छिपा हुआ कोड जोड़ें जो लंबे समय तक चलने वाली संगणनाओं को छोड़ देगा। यह कोड हो सकता है जो पाइपलाइन फिट/भविष्यवाणी करता है। फायदा: काम करता है। नुकसान: हाथ से चलने पर उपयोगकर्ताओं को जो मिलता है, उससे मेल नहीं खा सकता है, साथ ही छिपा हुआ कोड भ्रमित करने वाला है।
2. लंबे समय तक चलने वाली नोटबुक के लिए, स्थानीय रूप से एक बार प्री-रन करें और नोटबुक में आउटपुट सहेजें। यदि कोई पुन: चलाने के बजाय मौजूद है तो Nbsphinx सहेजे गए निष्पादन का उपयोग करेगा। फायदा: काम करता है। नुकसान: हम समय-समय पर आउटपुट को अपडेट करना भूल सकते हैं।
3. नोटबुक की कुछ सामग्री को सरल/हटाएं। उदाहरण के लिए, यदि संभव हो तो डेटा आकार को कम करने, मानदंड को रोकने आदि पर विचार करें। फायदा: स्पीडअप। नुकसान: टेक्स्ट जैसे कुछ उदाहरणों के लिए पूर्ण आउटपुट नहीं दिखा सकता।

मेरा सुझाव है कि हम विकल्प 2 के साथ जाएं, लेकिन विकल्प 3 को ध्यान में रखते हुए।

1627 को डुप्लिकेट के रूप में बंद कर दिया गया था, लेकिन मुझे लगता है कि वहां अभी भी कुछ ऐसा हो सकता है जो इस मुद्दे में शामिल नहीं था, इसलिए यहां पोस्ट करना:

मैंने देखा है कि दस्तावेज़ों को बनने में अधिक समय लग रहा है। मुझे लगता है कि यह संभव है क्योंकि infer_problem_types दिखाने के लिए स्तन कैंसर डेटा सेट (+ कहीं और?) के बजाय धोखाधड़ी डेटासेट का उपयोग करने के लिए ऑटोएमएल दस्तावेज़ों को c871f3b में बदल दिया गया था, क्योंकि स्तन कैंसर डेटासेट में केवल संख्यात्मक कॉलम होते हैं।

मुझे संदेह है कि यह पिछले 20 मिनट से लेकर अब> 30 मिनट तक, डॉक्स के और भी लंबे निर्माण समय के लिए एक अलग मुद्दा/कारण है, और यह ध्यान देने योग्य हो सकता है!

@dshery FYI करें

दस्तावेज़ बनाने के लिए एकाधिक प्रोसेसर का उपयोग करना एक और संभावित समाधान है:

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

@dserry के साथ निम्नलिखित चर्चा को अपडेट करें।

हमारे Makefile में -j ध्वज को जोड़ने से सर्कलसी पर build docs परीक्षण तेजी से समाप्त हो जाता है, जैसा कि यहां देखा गया

यह क्या एक सफल निर्माण दिखता ReadtheDocs के लिए पसंद है, पूरा करने के लिए 20 मिनट से कुछ अधिक समय ले रहा है। HTML और लेटेक्स के निर्माण समय के बीच का अंतर बताता है कि जुपिटर नोटबुक को स्वयं बनाने में अधिक समय नहीं लगता है, जो कि अच्छा है।

हालाँकि, हम ऐसे उदाहरण भी खोज रहे हैं जहाँ बिल्ड इस तरह विफल हो जाता है। हमने देखा कि किसी कारण से, ReadtheDocs दो बार कमांड का पूरा क्रम चला रहा है, जिसके कारण बिल्ड को अधिक समय लगता है (HTML और लेटेक्स फ़ाइलों को बनाने के लिए प्रत्येक में 30 मिनट से अधिक), और doc बिल्ड के विफल होने का कारण बनता है। यह देखने के लिए कि ऐसा क्यों हो रहा है और हम इसे कैसे ठीक कर सकते हैं, मैं ReadtheDocs सहायता टीम के साथ अनुवर्ती कार्रवाई करूंगा, और प्रतिक्रिया मिलने पर मैं यहां उन परिणामों के साथ अपडेट करूंगा।

@bchen1116 ने समर्थन से संपर्क किया और उन्होंने कहा

ऐसा लगता है कि इस बग का मूल कारण आपके पास सक्रिय संस्करणों की संख्या है। मुझे इससे संबंधित हमारे लॉग में कुछ त्रुटियां दिखाई देती हैं।
अभी के लिए इसे हल करने के लिए, आप अपने द्वारा रखे गए सक्रिय संस्करणों की संख्या को कम कर सकते हैं। ऐसा लगता है कि आप अलग-अलग शाखाओं या पुल अनुरोधों के लिए संस्करण बना रहे हैं, क्या आपने हमारी पुल अनुरोध निर्माण सुविधा की कोशिश की है? यह निर्मित सामग्री को बनाए रखते हुए, निर्माण के बाद अनावश्यक संस्करणों को हटाने में मदद करेगा।

मेरा मानना ​​​​है कि यहां संदर्भित "पुल रिक्वेस्ट बिल्डिंग फीचर" यह पुष्टि करता है।

अद्यतन:
हमने आरटीडी को केवल पुल अनुरोधों से बनाने के लिए अपडेट किया है, अनावश्यक बिल्ड को अलग-अलग संस्करणों (शाखाओं) में हटा दिया है जिसे हम धक्का देते हैं। इसके अतिरिक्त, हमने आरटीडी (विविध शाखाएं जिन्हें हम पीआर के लिए उपयोग करते हैं) से सभी अनावश्यक (अनटैग्ड) संस्करणों को हटा दिया है, जिससे लगता है कि दस्तावेज़ बनाने में मदद मिली है। हमें बिल्ड पर किसी भी दस्तावेज़ का समय समाप्त नहीं होता है, इसलिए हम कल इस मुद्दे को बंद कर देंगे जब तक कि हम फिर से टाइमआउट देखना शुरू नहीं करते।

@ bchen1116 क्या यह अब बंद होने योग्य है?

अब बंद हो रहा है, क्योंकि धीमी डॉक बिल्ड के साथ कोई समस्या नहीं है।