Selamat datang di Bagian 2 dari penelitian kami tentang kinerja snap Firefox. Untuk meminimalkan pengulangan, kami sarankan untuk memeriksa Bagian 1 Dalam seri ini Anda akan menemukan ringkasan pendekatan kami, daftar istilah, dan tip tentang kriteria standar.
Selamat datang kembali, penggemar Firefox! Saatnya untuk pembaruan lain di Firefox Immediate Improvements.
Firefox menawarkan banyak manfaat bagi pengguna Ubuntu sehari-hari serta berbagai distribusi Linux lainnya. Meningkatkan keamanan, menawarkan kompatibilitas lintas rilis, dan mempersingkat waktu upgrade Mozilla untuk menjangkau pengguna.
Saat ini, pendekatan kinerja ini memiliki kelemahan, terutama pada permulaan Firefox pertama setelah sistem dimulai ulang. Kumpulan ini mengikuti kemajuan kami dalam meningkatkan waktu mulai untuk memastikan kami memberikan pengalaman pengguna sebaik mungkin.
Sepanjang jalan, kami juga akan membahas masalah penggunaan khusus yang telah diidentifikasi dengan bantuan komunitas.
Mari kita lihat apa yang telah kita lakukan!
Area fokus saat ini
Di sini kami membahas koreksi terbaru, bidang minat baru yang diidentifikasi, dan pembaruan untuk penelitian profil kami.
Dukungan Notebook Jupyter – Diperbaiki
Ikuti topiknya
Untuk beberapa ilmuwan data, dukungan browser untuk Jupyter Notebook sangat penting untuk alur kerja mereka. Saat menyiapkan buku catatan, ada dua cara untuk melihatnya:
- Buka file di ~ / .local / share / jupyter / l
- Gulir ke satu http: //host lokal / URL
Jalur kedua lebih kompatibel dengan lingkungan kotak pasir dan tidak memiliki masalah dengan Snap Firefox. Namun, rekomendasi default adalah membuka file secara langsung. Ini menyebabkan masalah .lokal Tidak tersedia untuk bidikan terbatas, yang secara default membatasi akses ke direktori titik.
Kami telah mengintegrasikan solusi snapd yang mengakses antarmuka browser secara khusus ~ / .local / share / jupyter Untuk mengaktifkan alur kerja default, kami juga melaporkan masalah ke hulu dan menyarankan agar Anda mengubah teks bantuan untuk merujuknya. http: //host lokal / URL pertama sebagai perjalanan yang direkomendasikan pengguna.
Render perangkat lunak
Ikuti topiknya
Terakhir kali, kami berbicara tentang Firefox yang gagal menentukan driver GPU. Dalam hal ini, ini kembali ke rendering perangkat lunak pada perangkat seperti Raspberry Pi, yang secara signifikan memengaruhi kinerja. Untuk mengatasi masalah ini, kami telah memperbarui antarmuka snapd OpenGL untuk memungkinkan akses ke lebih banyak ID PCI, termasuk yang digunakan pada Rasberry Pi.
Namun, koreksi ini tampaknya tidak sepenuhnya menyelesaikan masalah ini. Masih ada laporan akselerasi yang diblokir oleh platform. Memecahkan masalah ini berpotensi membuat perbedaan besar di Raspberry Pi, jadi kami akan terus mengeksplorasi.
Manajemen ekstensi
Ikuti topiknya
Menyalin sejumlah besar paket bahasa di awal Firefox masih menjadi masalah konstan di semua kriteria kami.
Mozilla bermaksud untuk mencerminkan perubahan yang telah dibuat pada Firefox versi Windows. Kemampuan untuk memuat hanya satu area pada satu waktu menambah area sistem.
Dukungan perpesanan asli
Ikuti topiknya
Dukungan perpesanan asli Mengaktifkan fitur utama seperti perangkat 2FA dan ekstensi GNOME. Portal Desktop XDG baru terletak di Jammy, tetapi integrasi Firefox terus berlanjut. Semuanya berjalan dengan baik dan harus segera diperbaiki.
Instalasi jaringan
Ikuti topiknya
Firefox snap dan flatpak saat ini tidak dapat berinteraksi dengan berbagi jaringan. Ini adalah masalah dengan portal desktop XDG, yang berfungsi secara lokal. Fakta bahwa portal memilih file pemilih dari tunggangan ini di bilah sisi juga menambah kebingungan.
Sampai masalah portal teratasi, salah satu solusinya adalah mengakses mount / var / run / pengguna / USERUID / gvfs (Catatan: Anda perlu menginstal sekering gvfs, yang membuat titik koneksi lokal).
Kelola font dan ikon
Kriteria baru untuk mengelola font dan ikon di amd64 menunjukkan bahwa cache ikon, tema, dan font relatif kecil dalam hal penggunaan sumber daya. Firefox menghabiskan beberapa waktu untuk melakukan ini, sementara Chromium tidak. Untuk sebagian besar sistem, ini sekitar 300 milidetik, tetapi pada Raspberry Pi jauh lebih efektif (hingga 6-7 detik).
Studi menunjukkan bahwa proses penyimpanan I/O sangat kompak dan I/O jauh lebih lambat pada kartu SD dengan CPU Raspberry Pi 4.
Ini mungkin merupakan tanda dari masalah mendasar yang kami coba identifikasi.
Waktu syscall futex ().
Kami menganalisis perilaku jepret terbatas Firefox versus versi tidak terbatas, serta peluncuran Fireball terbatas dari tarball (tersedia untuk diunduh langsung dari situs Mozilla).
Dengan edisi terbatas, dalam ringkasan eksekusi strace, kami menemukan bahwa panggilan sistem futex () membutuhkan rata-rata sekitar 20.000 us di Kubuntu 22.04 dan sekitar 7.000 us di Fedora 36, yang keduanya diinstal pada perangkat keras yang sama. Angka-angka ini menunjukkan perbedaan dalam kunci memori, terutama jika dibandingkan dengan hasil serupa yang dikumpulkan dari versi Firefox yang terbatas atau tidak dapat diubah. Di sana, panggilan sistem futex () rata-rata hanya sekitar 20 us
Selain itu, kami menemukan bahwa versi snap menjalankan lebih banyak panggilan sistem Fuex () (serta yang lainnya). Beberapa di antaranya diharapkan, karena Snap yang berjalan berbeda dari aplikasi non-Snap, termasuk penggunaan Snap dan konten dasar, serta pembatasan keamanan.
Masalah ini telah dilaporkan secara konsisten pada berbagai platform perangkat keras dan distribusi Linux, dengan rata-rata waktu panggilan sistem futex () diamati secara linier dengan waktu boot yang diamati.
Misalnya, contoh ringkasan strace (strace -c) Dari implementasi langsung Firefox:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- -------------------
82.18 388.576521 18131 21431 2272 futex
10.31 48.737839 7583 6427 4 poll
4.09 19.350524 7660 2526 6 epoll_wait
1.50 7.114924 72601 98 38 wait4
0.69 3.258415 574 5676 2715 recvmsg
0.51 2.406544 41492 58 clock_nanosleep
0.13 0.633050 71 8843 5 read
0.12 0.564651 34 16452 11403 openatDan sebagai perbandingan, versi tar pada host yang sama:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- -------------------
46.13 0.397783 8 47957 clock_gettime
19.76 0.170379 21 7828 1245 futex
6.90 0.059470 8 6888 gettimeofday
5.22 0.044991 8 5353 4324 recvmsg
3.49 0.030111 8 3745 poll
2.57 0.022125 22125 1 wait4
1.75 0.015092 8 1829 read
1.68 0.014518 15 942 319 openatKami telah melihat hasil yang serupa dengan foto lain, termasuk Thunderbird serta Chromium. Sementara waktu startup yang sebenarnya bervariasi dari SNAP ke SNAP, perilaku keseluruhan konsisten dan menekankan perhitungan yang berlebihan dengan binari SNAP.
Kami mencoba memisahkan sumber fenomena ini dengan cara yang berbeda. Pertama, kami mencoba mencari tahu apakah pembatasan keamanan mungkin menjadi penyebab masalah manajemen memori yang dapat menyebabkan Firefox (dan binari lainnya) mengalami masalah saat mengunci ruang pengguna. Ini kemudian menjadi terlalu banyak panggilan sistem futex () dan waktu yang sangat lama per panggilan. Menonaktifkan kurungan AppArmor dan Seccomp tidak membuat kemajuan.
Demikian pula, kami menonaktifkan Firefox dengan kotak pasir bawaannya serta browser yang menggunakan tmalloc (untuk melihat apakah mungkin ada alasan lain untuk kebocoran memori), tetapi upaya ini tidak membaik saat startup.
Kami akan terus menyelidiki masalah ini dengan penyelidikan lebih lanjut dan peninjauan memori terhadap versi Snapd yang tidak terbatas.
tetap berhubungan
Ini semua untuk pembaruan minggu ini! Nantikan episode 3 dalam beberapa minggu ke depan. Pada saat yang sama, jangan lupa untuk waspada terhadap kolektor utama masalah dan umpan balik kami:
Jika Anda ingin memilih kriteria dan mengikuti peningkatan pada perangkat Anda, jangan lupa untuk membaca bagian kami “Membuat kriteria Anda sendiri” di bagian 1 dari koleksi ini dan membagikannya tentang topik wacana.
