Ya. Saya mengubah kriteria penghentian automl default menjadi max_batches=1 beberapa minggu yang lalu juga, yang tidak membantu.

Saya suka solusi yang Anda daftarkan! Ditambah satu dari saya sendiri:

1. Tambahkan beberapa kode tersembunyi di buku catatan yang akan melewatkan komputasi yang berjalan lama. Ini bisa berupa kode yang mengolok-olok kecocokan/prediksi pipa. Keuntungan: bekerja. Kekurangan: mungkin tidak sesuai dengan apa yang didapat pengguna saat dijalankan dengan tangan, ditambah kode tersembunyi yang membingungkan.
2. Untuk notebook yang berjalan lama, lakukan pra-jalankan secara lokal satu kali dan simpan hasilnya di notebook. Nbsphinx akan menggunakan eksekusi yang disimpan jika ada alih-alih menjalankan kembali. Keuntungan: bekerja. Kekurangan: kita mungkin lupa untuk memperbarui output secara berkala.
3. Sederhanakan/hapus beberapa isi buku catatan. Misalnya, pertimbangkan untuk menurunkan ukuran data, menghentikan kriteria, dll. jika memungkinkan. Keuntungan: speedup. Kerugian: tidak dapat menampilkan output penuh untuk beberapa contoh, seperti teks.

Saya sarankan kita menggunakan opsi 2, tetapi dengan opsi 3 dalam pikiran.

1627 ditutup sebagai duplikat, tetapi saya pikir mungkin masih ada sesuatu di sana yang tidak tercakup dalam masalah ini, jadi posting di sini:

Saya perhatikan bahwa pembuatan dokumen membutuhkan waktu lebih lama. Saya pikir ini mungkin karena dokumen automl diubah di c871f3b untuk menggunakan kumpulan data penipuan, alih-alih kumpulan data kanker payudara (+ di tempat lain?) untuk menampilkan infer_problem_types, karena kumpulan data kanker payudara hanya memiliki kolom numerik.

Saya menduga ini adalah masalah/alasan yang berbeda untuk waktu pembuatan dokumen yang lebih lama, dari 20 menit sebelumnya hingga sekarang >30 menit, dan dapat disebutkan!

@dsherry FYI

Solusi lain yang mungkin adalah menggunakan beberapa prosesor untuk membuat dokumen:

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

Perbarui diskusi berikut dengan @dsherry.

Menambahkan flag -j ke Makefile memungkinkan pengujian build docs pada circleci selesai lebih cepat, seperti yang terlihat di sini . Sayangnya, ReadtheDocs tidak menjalankan perintah ini, yang berarti bahwa pembuatan dokumentasi yang dipublikasikan masih membutuhkan waktu dan sering error.

Seperti inilah tampilan build yang sukses untuk ReadtheDocs, membutuhkan waktu lebih dari 20 menit untuk menyelesaikannya. Perbedaan antara waktu pembuatan HTML dan Lateks menunjukkan bahwa membuat notebook Jupyter sendiri tidak memakan banyak waktu, dan itu bagus.

Namun, kami juga menemukan contoh di mana pembangunan gagal seperti ini . Kami memperhatikan bahwa untuk beberapa alasan, ReadtheDocs menjalankan urutan penuh perintah dua kali, yang menyebabkan build memakan waktu lebih lama (masing-masing lebih dari 30 menit untuk membuat file HTML dan lateks), dan menyebabkan doc build gagal. Saya akan menindaklanjuti dengan tim dukungan ReadtheDocs untuk melihat mengapa ini terjadi dan bagaimana kami dapat memperbaikinya, dan saya akan memperbarui dengan hasil tersebut di sini ketika saya mendapatkan umpan balik.

@bchen1116 menghubungi dukungan dan mereka berkata

Sepertinya penyebab utama dari bug ini adalah jumlah versi aktif yang Anda miliki. Saya melihat beberapa kesalahan dalam log kami yang terkait dengan ini.
Untuk mengatasinya untuk saat ini, Anda dapat mengurangi jumlah versi aktif yang Anda simpan. Sepertinya Anda sedang membangun versi untuk masing-masing cabang atau permintaan tarik, sudahkah Anda mencoba fitur pembuatan permintaan tarik kami? Ini akan membantu menghapus versi yang tidak diperlukan setelah membangun, sambil tetap mempertahankan konten yang dibuat.

Saya percaya "fitur pembuatan permintaan tarik" yang dirujuk di sini adalah this , mengkonfirmasikan.

Memperbarui:
Kami telah memperbarui RTD untuk membangun dari permintaan tarik saja, menghapus build yang tidak perlu ke berbagai versi (cabang) yang kami dorong. Selain itu, kami telah menghapus semua versi yang tidak perlu (tanpa tag) dari RTD (cabang lain-lain yang kami gunakan untuk PR), yang tampaknya telah membantu pembuatan dokumen. Kami tidak melihat adanya batas waktu dokumen pada build, jadi kami akan menutup masalah ini besok kecuali kami mulai melihat batas waktu lagi.

@ bchen1116 apakah ini bisa ditutup sekarang?

Tutup sekarang, karena tidak ada masalah dengan pembuatan dokumen yang lambat.