Dari penerjemah: masalah perangkat lunak lambat telah menjadi salah satu topik utama diskusi tentang Habré dan Hacker News dalam beberapa minggu terakhir. Sebagai contoh, lihat artikel Nikita Prokopov "Kekecewaan Saya dalam Perangkat Lunak" dan 2432 komentar tentang itu.

Kami menghabiskan banyak waktu di depan komputer. Kami menunggu setiap kali Anda meluncurkan aplikasi dan memuat halaman web. Di mana-mana ada ikon pemintal atau jam pasir. Besi menjadi lebih kuat, tetapi perangkat lunak tampaknya masih lambat. Kenapa begitu

Jika Anda menggunakan komputer untuk melakukan pekerjaan penting, Anda layak mendapatkan perangkat lunak cepat. Terlalu sering, perangkat lunak modern tidak memenuhi persyaratan ini. Di laboratorium penelitian Ink & Switch, kami mempelajari alasan untuk situasi ini, perangkat lunak akhirnya menjadi lebih baik. Artikel ini menerbitkan hasil penelitian kami.

Daftar isi

Di mana tepatnya kelambatan itu

Apa yang dirasakan oleh pengguna sebagai program "lambat"? Terkadang perangkat lunak mengganggu kita semua dengan keterlambatan dan keterlambatan. Tetapi untuk lebih memahami masalah ini, sensasi intuitif harus dilengkapi dengan studi akademik yang secara ketat menjawab pertanyaan ini.

Kecepatan yang dirasakan terkait erat dengan konsep latensi. Perbandingan penelitian ilmiah tentang "apa yang tampaknya lambat" dengan pengukuran keterlambatan nyata dalam aplikasi ini memperjelas seberapa buruk semuanya.

Keterlambatan bukan bandwidth

Ketika membahas kinerja perangkat lunak, kita sering mendengar tentang bandwidth. Misalnya, "server web ini dapat menjalankan 10.000 permintaan per detik." Tapi bukan itu yang dilihat pengguna. Mereka peduli tentang berapa lama permintaan web khusus mereka atau berapa lama untuk membuka dokumen, atau seberapa cepat aplikasi merespons terhadap klik mouse. Interaksi ini dikaitkan dengan latensi. Keterlambatan adalah metrik kritis yang akan kita pelajari dalam artikel ini.

Persepsi Pengguna
Untuk informasi lebih lanjut tentang pentingnya latensi dalam sistem interaktif, lihat di sini .

Faktor-faktor lain mempengaruhi perasaan kecepatan perangkat lunak. Misalnya, frame rate dan umpan balik selama tugas panjang. Tetapi kami percaya bahwa latensi adalah metrik dasar, dan dengan latensi sangat rendah, perangkat lunak apa pun akan terasa sangat cepat.

Antarmuka sentuh

Pertama, pertimbangkan sensitivitas manusia terhadap penundaan layar sentuh.

Peneliti memverifikasi ini dengan tes yang menentukan dengan tepat apa yang dirasakan pengguna penundaan. Pertama, subjek ditawarkan antarmuka dengan (katakanlah) penundaan 1 ms, dan kemudian (katakanlah) 70 ms, dan diminta untuk melakukan operasi seperti menekan tombol. Jika antarmuka 70 ms secara konsisten menunjukkan hasil yang lebih buruk daripada antarmuka 1 ms, maka 70 ms disebut "perbedaan nyata".

Perbedaan mencolok minimal
Untuk detail lebih lanjut tentang perbedaan keterlambatan minimum yang terlihat dan fasilitas eksperimental terkait, lihat, misalnya, pekerjaan ini .

Perbedaan minimum yang terlihat adalah anggaran, setelah itu operasi tertentu akan mulai terasa lambat bagi pengguna.

Misalnya, ketika menyeret item di layar, pengguna hanya merasakan keterlambatan ~ 2 ms. Penundaan yang paling tidak terlihat tergantung pada pengguna dan tindakan yang dilakukan, tetapi selalu sangat rendah.

Persepsi drag and drop
Laporan persepsi 2-16 ms saat menyeret dengan stylus .
2-11 ms saat menyeret dengan jari .
Rata-rata 11 ms saat menyeret dengan jari .

Hasil serupa diperoleh ketika menggambar dengan stylus pada tablet. Di sini, para peneliti menyarankan pengguna memperhatikan penundaan 20 hingga 80 ms. Dalam pengujian tidak resmi kami sendiri, penundaan sekitar 80 ms terlihat sangat nyata, dan dibutuhkan sesuatu yang lebih dekat hingga 20 ms agar stylus terlihat responsif selama tulisan tangan.

Stylus menunda persepsi
Laporkan persepsi keterlambatan 10−70 ms saat menulis dengan stylus .
21–82 ms untuk berbagai tindakan dengan stylus .

Perbedaan antara latensi tulisan tangan rendah dan tinggi jelas ketika membandingkan:

Kiri: Aplikasi iPad Pro dan Notes dengan latensi ujung ke ujung sekitar 15 ms. Kanan: Aplikasi Samsung S3 dan OneNote dengan penundaan sekitar 70 ms. Video 16 kali lebih lambat.

Operasi khas lainnya pada perangkat sentuh adalah mengklik tombol atau tautan. Di sini, tes menentukan bahwa pengguna melihat penundaan sekitar pergantian 70 ms (meskipun mungkin lebih rendah untuk beberapa pengguna individu).

Persepsi keterlambatan layar
Studi ini mengungkapkan keterlambatan dibedakan minimum rata-rata 69 ms.

Berikut adalah contoh yang membandingkan dua penundaan berbeda:

Kiri: membuka tab pengaturan pada iPhone 6s dengan penundaan sekitar 90 ms. Kanan: beralih pengaturan pada Samsung S3 dengan penundaan sekitar 330 ms. Video 16 kali lebih lambat.

Bagaimana aplikasi modern memenuhi ambang batas ini? Jika kita berbicara tentang drag and drop, maka tidak ada sistem komersial yang dapat secara konstan sesuai dengan penundaan beberapa milidetik untuk memuaskan semua konsumen.

Seret dan Jatuhkan Performa
Seperti yang akan kita lihat di bawah ini, bahkan tampilan dan peralatan untuk entri data tidak sesuai dengan anggaran 10 ms, belum lagi beberapa lapisan perangkat lunak.

Dengan demikian, ketika menggunakan semua sistem operasi saat ini dengan layar sentuh, setidaknya beberapa pengguna akan merasa bahwa objek berada di belakang jari Anda ketika menarik dan menjatuhkan.

Saat menggambar dengan stylus, sejumlah kecil sistem mendekati tingkat keterlambatan yang dapat diterima. Tetapi kebanyakan dari mereka jauh lebih tinggi dari nilai-nilai ini, yang diharapkan oleh pengguna sebagai penundaan yang signifikan:

Di bawah ini adalah hasil dari tes Ink & Switch pada keterlambatan menggambar dengan stylus pada tablet untuk berbagai perangkat. Penundaan rata-rata, diukur dari kontak dengan layar ke awal perubahan warna piksel yang sesuai, dibulatkan ke 5 ms terdekat.

Perangkat	Programnya	Keterlambatan (ms)
iPad Pro	Catatan	20
	Catatan bagus	30
	Bergetar	35
Permukaan pro	OneNote	25
	Sketsa	30
	Kanvas	60
Pixelbook	Cumi-cumi	40
	Kanvas	60
Samsung s3	Cumi-cumi	60
	Bergetar	65
	Kanvas	75
	Papan tulis	80

Meskipun kami tidak memiliki data tentang keterlambatan pada semua perangkat, kami menganggap bahwa data tersebut sebanding dengan keterlambatan menggambar stylus yang diamati di atas.

Menarik penundaan dibandingkan penundaan klik
Kami berharap penundaan ini sebanding, karena dalam kedua kasus, input sentuh digunakan, yaitu, siklus penyegaran layar diaktifkan. Namun, ada beberapa perbedaan, sehingga nilainya tidak mungkin persis sama.

Karena penundaan sekitar 70 ms dapat dilihat di sini, sebagian besar sistem mampu merespons klik dengan baik. Tetapi juga mudah untuk menemukan aplikasi yang bekerja jauh lebih buruk daripada kemampuan teoritis sistem.

Secara umum, sistem sensorik harus memiliki latensi yang sangat rendah untuk membuatnya merasa responsif. Sebagian besar perangkat dan aplikasi tidak dapat memberikan tingkat kinerja ini, dan karena itu mereka semua merasa, pada tingkat yang berbeda, lambat bagi pengguna.

Keyboard

Ada beberapa bukti bahwa peningkatan latensi pengetikan merusak pengalaman pengguna.

Pengaruh Keterlambatan Input
Dalam penelitian ini, penundaan acak ditambahkan ke penekanan tombol, yang mengurangi kinerja input. Namun, itu hanya mengevaluasi satu rentang penundaan. Selain itu, penulis penelitian menyarankan bahwa huruf yang berpengalaman dapat beradaptasi dengan peningkatan latensi.

Namun, kami tidak mengetahui penelitian yang secara spesifik mengukur keterlambatan input yang paling tidak terlihat. Penundaan dalam menekan layar sentuh (terlihat sekitar 70 ms) dapat menjadi panduan yang bermanfaat karena juga mengukur waktu antara sentuhan jari yang berbeda dan penyegaran visual layar.

Di bawah ini adalah beberapa pengukuran informal dari penundaan keyboard ujung-ke-ujung dari awal penekanan tombol hingga penampilan karakter di berbagai mesin. Sumber: "Latensi komputer: 1977−2017" , tes Ink & Switch.

Komputer	Keterlambatan (ms)
Apple iie	30
Commodore Pet 4016	60
iMac g4 OS 9	70
Macbook Pro 2014	100
Kustom Haswell-e 24Hz	140
Samsung s3	150
Powerspec g405 Linux	170
Simbol 3620	300

Pengukuran akurat dari efek latensi keyboard akan menjadi percobaan yang bagus untuk para peneliti petualang. Dalam kasus apa pun, tampaknya bagi banyak pengguna ambang untuk keterlambatan nyata saat memasukkan dari keyboard di bawah 100 ms. Mungkin jauh lebih rendah.

Seekor tikus

Jenis perangkat input terbaru dalam ulasan kami. Satu percobaan menentukan bahwa pengguna merasakan latensi mouse mulai dari 34 hingga 137 ms dengan rata-rata 65 ms.

Tikus yang berbeda memiliki nilai penundaan yang sangat berbeda. Beberapa sistem menunjukkan nilai kurang dari 10 ms dengan menggabungkan peralatan berkinerja tinggi dengan pemrograman tingkat rendah yang hati-hati ( ini menjelaskan pemasangan dengan penundaan sekitar 8 ms). Selain itu, Anda dapat melampaui 100 ms pada kombinasi peralatan biasa-biasa saja dan aplikasi yang menyebabkan penundaan tambahan, atau buffer antara mouse dan layar.

Aplikasi

Penundaan tingkat aplikasi mengukur berapa lama waktu yang diperlukan untuk melakukan tindakan aplikasi tertentu, seperti memuat halaman web. Contoh dari penundaan tersebut adalah memuat halaman web NYTimes, yang memakan waktu sekitar 3000 ms.

Kapan tindakan aplikasi tampak cepat? Sulit untuk mengatakan dengan pasti, karena tindakan mereka lebih kompleks dan beragam daripada entri data sederhana. Mungkin, jawabannya juga tergantung pada harapan pengguna (saat ini biasanya orang bekerja dengan perangkat lunak lambat). Tapi kita bisa menghitung perkiraan angka.

Keterlambatan Sastra
Lihat ulasan literatur tentang efek keterlambatan pada pengguna aplikasi yang berbeda. Ini adalah titik awal yang baik untuk perendaman yang lebih dalam dalam topik ini.

Salah satu nilai referensi adalah metrik 70 ms sebagai penundaan paling tidak terlihat yang disebutkan di atas saat Anda mengklik layar. Jika Anda melihat penundaan antara mengklik tautan dan menampilkan indikator klik, Anda harus memperhatikan penundaan yang sama antara mengklik dan membuka halaman web.

Referensi lain adalah model pengembang Google RAIL . Meskipun penulis model ini tidak membuktikan pernyataan mereka dengan cara apa pun, model mengklaim bahwa respons dalam 100 ms "terasa instan" dan penundaan yang lebih tinggi "[memutus] hubungan antara aksi dan reaksi".

Anda dapat secara tidak resmi memeriksa sensitivitas Anda sendiri di terminal. Ambil program baris perintah favorit Anda dan jalankan dengan parameter 'waktu', yang mengukur waktu eksekusi. Tentunya perhatikan perbedaan antara respons selama 15 ms (sangat baik!) Dan 500 ms (jelas lambat).

Sebagai titik referensi terakhir, kami memperhitungkan bahwa waktu reaksi manusia yang khas terhadap stimulus visual adalah sekitar 220 ms .

Nilai ini jauh lebih besar daripada keterlambatan nyata, karena reaksi tidak hanya mencakup pengamatan, tetapi juga tindakan selanjutnya.

Penting juga untuk memperhitungkan kesimpulan dari beberapa peneliti bahwa seseorang dapat merasakan peningkatan keterlambatan pada tingkat fisiologis yang tidak disadari.

Aplikasi nyata

Bagaimana aplikasi yang sebenarnya sesuai dengan pedoman ini? Ada yang mengatasi. Sebagai contoh, banyak program baris perintah Unix berjalan lebih cepat dari 100 ms.

Tetapi sebagian besar aplikasi internet berada di luar jangkauan. Pencarian Google di sekitar 1000 ms jauh lebih cepat daripada kebanyakan aplikasi web, tetapi masih terasa lebih lambat dibandingkan dengan kurang dari 100 ms pada baris perintah. Dan mudah untuk menemukan contoh halaman yang memuat lebih dari 5000 ms bahkan pada koneksi yang baik.

Dalam kasus komputer seluler dan desktop, ada beberapa aplikasi yang secara konsisten menunjukkan penundaan kurang dari 100 ms, seperti kalkulator bawaan di iOS. Tetapi mudah untuk menemukan contoh aplikasi yang jauh melebihi ambang ini, bahkan jika mereka memiliki semua data yang tersedia (atau seharusnya) secara lokal. Perhatikan contoh Slack.

Video di bawah ini menunjukkan bahwa beralih antara dua saluran volume rendah di ruang kerja yang sama pada iPad Pro membutuhkan waktu sekitar 220 ms, meskipun tidak perlu untuk panggilan jaringan, dan iPad Pro bisa dibilang sebagai perangkat seluler berperforma tertinggi di dunia (video diperlambat 8 kali lipat ):

Sulit untuk menarik kesimpulan umum untuk semua program dalam bidang yang luas seperti penundaan tindakan. Namun demikian, tampak jelas bahwa beberapa aplikasi melakukan tindakan dengan cukup cepat dan tampak instan bagi pengguna (kurang dari 100 ms), tetapi banyak aplikasi tidak.

Dari mana datangnya pelambatan?

Jadi, kami menemukan bahwa banyak program sebenarnya bekerja lambat. Kemana perginya selama ini dan apa yang bisa kita optimalkan? Pertimbangkan masalah ini, dimulai dengan komponen pertama dalam rantai: perangkat input.

Perangkat input

Langkah pertama dalam pipeline, yang mengubah data input fisik menjadi pembaruan di layar, adalah pemrosesan data input: mengubah kontak dengan layar sentuh, keyboard, atau mouse menjadi sinyal digital untuk sistem operasi. Di sini kita melihat berapa lama langkah ini berlangsung.

Mari kita mulai dengan keyboard. Tabel menunjukkan penundaan yang diukur dari awal penekanan tombol ke sinyal pada hub USB, dibulatkan hingga 5 ms ( sumber ).

Keyboard	Keterlambatan (ms)
Sihir apel	15
Das 3	25
Gaya bebas Kinesis2	30
Ergodox	40
Keuntungan Kinesis	50
Logitech MK360	60

Seperti yang Anda lihat, keyboard ini dengan mudah mengambil puluhan milidetik dari anggaran pada langkah pertama dalam pipa pemrosesan. Ini dari total anggaran 100 ms atau kurang! Topik ini dibahas lebih rinci dalam artikel “Mencetak dengan senang hati” .

Tikus juga mengambil puluhan milidetik dari anggaran. Meskipun gaming mouse paling tinggi memiliki penundaan kurang dari 10 ms. Data pada respons terhadap penekanan bervariasi, di sini, juga, setiap instance menunjukkan hasil kurang dari 10 ms ( contoh ).

Pada perangkat seluler, lebih sulit untuk mengukur proporsi keterlambatan yang jatuh pada perangkat input karena mereka terintegrasi dengan komponen perangkat keras lainnya. Namun, kami dapat menggunakan beberapa pola umum dalam peralatan perangkat input untuk mengevaluasi penundaannya, serta perangkat yang berdiri sendiri.

Tingkat pengambilan sampel

Satu pola umum adalah laju sampling. Di banyak perangkat input, peralatan "memindai" atau "sampel" input secara berkala. Misalnya, layar sentuh konsumen yang khas beroperasi pada frekuensi 60 Hz, yaitu, ia melakukan polling sensor sekitar setiap 17 ms. Ini berarti bahwa dalam kasus terburuk, penundaan perangkat input setidaknya 17 ms, dan rata-rata tidak lebih dari 8 ms.

Semua hal sama, kecepatan pemindaian yang lebih tinggi akan mengurangi penundaan input. Misalnya, layar sentuh dan stylus canggih Apple beroperasi pada frekuensi di atas 60 Hz (informasi dari arsip dokumentasi Apple ).

Perangkat	Layar sentuh (Hz)	Stylus (Hz)
iPhone 6	60
iPhone 7	60
iPhone 8	60
iPhone X	120
iPad Air 2	60
iPad Mini 4	60
iPad Pro	120	240

Sumber keterlambatan serupa adalah polling USB. Protokol USB menerima input dari keyboard, sehingga keyboard perlu menunggu jajak pendapat USB untuk mengirim informasi tentang klik. Polling USB kecepatan rendah berjalan pada 125 Hz, memperkenalkan ~ 8 ms maks. dan ~ keterlambatan rata-rata 4 ms. Versi USB scan berikutnya dengan frekuensi 1000 Hz atau lebih, meminimalkan efek penundaan.

Ada banyak sumber potensial keterlambatan lainnya dalam perangkat input, misalnya, kontak bouncing (untuk lebih jelasnya lihat artikel "Memindai matriks keyboard dan kontak bouncing" tentang efek perangkat lunak dan perangkat keras bouncing).

Kami tidak akan mempertimbangkan semua nuansa ini di sini, tetapi kami menekankan yang utama: a) perangkat input itu sendiri dapat menyebabkan penundaan yang signifikan sebelum pemrosesan dalam perangkat lunak terjadi; b) ini mungkin karena beberapa alasan terpisah, dan waktu tunda ditambahkan.

Layar dan GPU

Perangkat keras di ujung konveyor adalah display dan kartu video.

Salah satu sumber keterlambatan di sini adalah laju bingkai tampilan. Karena tampilan tidak dapat digambar ulang terus-menerus, ini menyebabkan penundaan yang tak terhindarkan mirip dengan perangkat input polling yang dijelaskan di atas. Jika layar diperbarui (katakanlah) setiap 20 ms, maka ia menambahkan 20 ms keterlambatan dalam kasus terburuk dan rata-rata 10 ms.

Persepsi gerak
Faktor-faktor lain memengaruhi persepsi kita tentang objek yang bergerak di layar. Blur Busters adalah sumber yang bagus untuk subjek ini. Sebagai contoh, lihat Artefak Gerakan LCD 101 .

Sebagian besar layar beroperasi pada 60 Hz, meskipun perangkat profesional dan tampilan permainan beroperasi pada 120 Hz, 144 Hz, dan 240 Hz. Dengan demikian, hanya frame rate tampilan biasanya menambah penundaan rata-rata sekitar 8 ms, meskipun dalam display dengan frame rate tertinggi dapat dikurangi menjadi beberapa milidetik.

Kontribusi lain terhadap keterlambatan tampilan adalah waktu yang diperlukan untuk secara fisik mengubah warna piksel setelah menerima data baru. Waktu ini bervariasi dari beberapa milidetik dalam tampilan game kelas atas hingga nilai dua digit dalam LCD yang kurang responsif.

Tampilkan waktu respons
Parameter ini sulit diukur, tetapi beberapa data ilustratif tersedia di situs web Cek Notebook . Misalnya, lihat contoh tampilan lambat dan cepat .

Pada perangkat modern kelas atas, layar terhubung ke prosesor grafis khusus (GPU). GPU membuat array piksel untuk tampilan, misalnya, dengan mengatur layer 2D atau rendering adegan virtual 3D. GPU menghasilkan bingkai dengan kecepatan yang tergantung pada perangkat keras GPU, interaksi dengan aplikasi dan kode platform, dan kadang-kadang pada logika sinkronisasi dengan tampilan.

Masalah terkait terjadi ketika kode aplikasi sangat lambat dan tidak mengirim instruksi ke GPU dengan cukup cepat untuk menggunakannya sepenuhnya. Ini dapat menyebabkan GPU membuat bingkai unik dengan kecepatan lebih rendah daripada jika benar-benar sering mendapatkan instruksi dari aplikasi. Ini adalah sumber umum kelambatan yang kita lihat dalam aplikasi 2D yang menampilkan kurang dari 60 frame per detik.

Lagi
Lagi tipe 'rongsokan' sulit untuk menggambarkan dengan kata-kata, tetapi mereka mudah dikenali. Nathan Gitter, dalam artikel Merancang Aplikasi Jank-Free , mendefinisikannya sebagai "gangguan visual yang tidak terduga atau mengganggu."

Hamparan lingkaran

Kami membahas setidaknya tiga bagian dari saluran pipa di mana terdapat penundaan karena aktivitas terputus-putus: pemindaian input, siklus perenderan GPU, dan siklus tampilan peragaan. Penting untuk dicatat bahwa mereka dapat digabungkan sedemikian rupa sehingga pada dasarnya semua penundaan bertambah:

Menunggu beberapa siklus. Kaskade tunda hipotetis menunjukkan bagaimana menunggu siklus perangkat keras berturut-turut dapat mengakumulasi penundaan. Garis vertikal putus-putus menunjukkan siklus konveyor yang diharapkan.

Untuk menuju ke langkah berikutnya dalam pipa, kita harus menunggu sampai siklus berikutnya. Dan loop mungkin tidak selaras satu sama lain. Siklus yang tidak konsisten dan waktu input awal yang tidak menguntungkan dapat menyebabkan penundaan tambahan 10 milidetik. Ini adalah jumlah yang besar dibandingkan dengan keterlambatan anggaran yang dijelaskan di atas.

Overhead runtime

Di sisi perangkat lunak, penundaan runtime melekat dalam sistem operasi dan kode lain yang tidak terkait langsung dengan aplikasi. Pertimbangkan dua contoh penting: pengumpulan dan penjadwalan sampah.

Pertama, pengumpulan sampah (GC). GC sangat penting dalam dua platform yang paling banyak digunakan di dunia: web (JavaScript) dan Android (Java).

Dalam beberapa kasus, pengumpulan sampah dapat menyebabkan keterlambatan yang besar, terutama mengenai persyaratan untuk penundaan input yang rendah. Untuk lingkungan JavaScript atau Java, penundaan pengumpulan sampah sekitar 10 ms tidak mengejutkan. Tapi itu semua anggaran untuk menyeret objek di layar sentuh!

Pengumpulan sampah dapat menunda hanya satu frame. Tetapi seperti dalam kasus keterlambatan karena kehilangan bingkai, tersentak seperti itu mengganggu pengguna.

Ada cara untuk mengurangi keterlambatan GC. Ini termasuk memindahkan sebanyak mungkin pekerjaan GC di luar utas utama, dan mengoptimalkan GC hanya untuk beberapa jeda yang terpisah. Lihat, misalnya, upaya V8 untuk memindahkan sebanyak mungkin operasi pengumpulan sampah dari arus utama dan upaya Go untuk memaksimalkan keterlambatan GC secara signifikan kurang dari 1 ms.

Ada pilihan lain untuk menggunakan bahasa pemrograman yang sebagian mengorbankan kenyamanan GC, tetapi memiliki kinerja yang lebih dapat diprediksi. Bahasa seperti Swift menghindari pengumpulan sampah sembarang menggunakanpenghitungan referensi otomatis .

Sumber potensial lain dari overhead adalah pelepasan sistem operasi. Aplikasi kita (dan ketergantungannya pada OS) tidak selalu bekerja secara konstan. Program lain dapat dijadwalkan untuk diluncurkan, sementara program kami ditangguhkan secara paksa, meskipun untuk waktu yang sangat singkat. Setiap program membutuhkan waktu, dan jumlah inti prosesor terbatas.

Masalah pengiriman terkait dengan pemanfaatan CPU. Jika aplikasi Anda memenuhi sasaran kinerjanya, tetapi membutuhkan hampir 100% sumber daya komputasi, ini dapat mengganggu pengguna. Konsumsi baterai akan meningkat, perangkat akan memanas dan mungkin mulai mengeluarkan suara dengan kipas. Dengan kata lain, ceteris paribus, pemanfaatan CPU yang rendah lebih baik bagi pengguna.

Penundaan yang disengaja

Sumber khas keterlambatan antarmuka ponsel adalah desain OS itu sendiri dan aplikasi. Ada beberapa interaksi penting yang hanya dapat dicapai dengan harapan nyata.

Android dan iOS banyak menggunakan "tekan lama" untuk mengakses menu konteks. Mereka mengharuskan pengguna untuk menunggu ratusan milidetik untuk menjalankan perintah.

Ada penundaan terkait dengan ini untuk menghilangkan ambiguitas. Misalnya, di Safari seluler ada penundaan default 350 ms antara saat pengguna mengklik tautan dan saat browser mulai memuat halaman baru. Ini diperlukan untuk menentukan perbedaan antara mengklik tautan dan ketuk dua kali (zoom). Untuk keterlambatan khusus ini, lihat di sini untuk detail lebih lanjut.. Ada juga informasi tentang perubahan terbaru yang memungkinkan pengembang aplikasi untuk mengatasi masalah ini.

Agen yang bermusuhan

Sumber umum keterlambatan bagi pengguna di Internet adalah aktivitas jahat, misalnya, pelacak aktivitas yang melacak tindakan pengguna dan mengunduh iklan yang mengganggu.

Artikel berisi 500 kata di situs web Washington Post membutuhkan sekitar seratus permintaan HTTP dan membutuhkan waktu sekitar 4400 ms untuk dimuat. Banyak pertanyaan diperlukan untuk pelacak dan iklan. Sebagian kecil dari mereka ditampilkan.

Ada banyak artikel bagus tentang obesitas di Web: lihat The Bullshit Web , “The Crisis of Obesity Sites” , Web mengasapi dan lain-lain. Kami

hanya menekankan bahwa sumber keterlambatan terbesar di banyak situs adalah mengunduh semua jenis omong kosong terhadap keinginan pengguna.

Kode aplikasi

Sumber terakhir dari keterlambatan yang kami sebutkan mungkin adalah yang paling jelas: ini adalah aplikasi itu sendiri. Jika suatu aplikasi menghabiskan banyak waktu pemrosesan input atau melakukan suatu tindakan, maka itu akan lambat.

Menyatukan semuanya

Pertimbangkan contoh dari apa total keterlambatan dibuat: Contoh

hipotetis dari keterlambatan ujung ke ujung dari input untuk ditampilkan di layar. Garis vertikal putus-putus menunjukkan siklus yang harus diharapkan oleh konveyor.Contoh

di atas adalah hipotetis, tetapi indikatif. Ini menunjukkan berapa banyak lapisan menambahkan penundaan, sehingga aplikasi bisa sangat lambat, bahkan jika itu berjalan pada kecepatan bingkai penuh.

Untuk perangkat lunak cepat

Tumpukan teknologi yang mendalam bertanggung jawab untuk merespons antarmuka komputer modern dengan tindakan pengguna. Bahkan keystroke sederhana pada keyboard dan penampilan karakter yang sesuai di kotak teks input adalah operasi yang melewati serangkaian langkah-langkah panjang yang kompleks: dari pemindaian keyboard, melalui lapisan pemrosesan OS dan kerangka kerja, melalui rendering kartu video dan kecepatan refresh tampilan.

Ada alasan untuk kompleksitas seperti itu, namun kami sedih bahwa pengguna komputer yang mencoba untuk bekerja secara produktif sering kali masih menunggu, menonton ikon jam pasir dan merasa bahwa perangkat mereka tidak bisa mengikuti mereka.

Kami percaya bahwa perangkat lunak cepat memberdayakan pengguna dan membuat mereka lebih produktif. Kita tahu bahwa perangkat lunak saat ini sering gagal bagi pengguna, lambat, dan kami ingin memperbaiki situasinya. Kami berharap materi ini bermanfaat bagi Anda ketika mengerjakan perangkat lunak Anda sendiri.

Sastra

1. Endo, Wang, Chen, Seltzer. "Mengevaluasi efektivitas sistem interaktif melalui penundaan» , Prosiding 2 USENIX Simposium Desain Sistem Operasi dan Implementasi , 1996.

2. Ng, Annette, Dietz, Gupta, Bischoff. "Dalam waktu: studi delay persepsi interaksi dengan stylus» , Prosiding 32 Tahunan ACM Konferensi Faktor Manusia di Computing Systems , 2014.

3. Ng Lepinsk, Vigdor, Sanders, Dietz. "Pengembangan perangkat dengan input sentuhan langsung dengan latensi rendah" , Prosiding Simposium ACM Tahunan ke-25 tentang Perangkat Lunak dan Teknologi Antarmuka Pengguna , 2012.

4. Deber, Jota, Forlays, Wigdor.“Kecepatan apa cukup? Persepsi pengguna tentang keterlambatan dan peningkatannya dalam antarmuka sentuh langsung dan tidak langsung ” , Prosiding Konferensi ACM Tahunan ke-33 tentang Faktor Manusia dalam Sistem Komputer , 2015.

5. Annette, Ng, Ditz, Bischof, Gupta. “Ke level mana seseorang harus pergi? Understanding the Delay Perception of Drawing ” , Prosiding Graphics Interface 2014 , 2014.

6. Forch, Franke, Rauch, Krems. "Apakah 100 ms sudah cukup?" Karakterisasi ambang batas persepsi keterlambatan dalam interaksi dengan mouse ” , Teknik Psikologi dan Ergonomi Kognitif: Kognisi dan Desain , 2017.

7. Dabrowski, Manson."40 tahun dari sistem komputer untuk menemukan waktu respon terbaik» , Berinteraksi dengan Komputer memiliki , 2011.

8. Barreda-Angeles, Arapakis, Bai, Kambazoglu sebelumnya. "Pengaruh efek find delay fisiologis sadar pada pengguna dan klik mouse mereka» , ke-38 International, SIGIR Konferensi ACM pada Penelitian dan Pengembangan Informasi Bagian Retrieval 2015.

Perangkat lunak lambat