Apakah optimasi mikro layak dilakukan di perangkat seluler?


8

Biasanya optimasi mikro dianggap tidak layak dengan penjelasan berikut: mungkin mempercepat program kurang dari satu persen, tetapi tidak ada yang peduli dengan dorongan kecil itu - itu hanya sedikit perubahan yang harus diperhatikan.

Selain itu, mungkin ada beberapa event handler yang menyala seribu kali per detik dan keluar dengan sangat cepat - sebelum dipecat lagi. Tidak ada yang peduli seberapa cepat itu - membuatnya lebih cepat tidak dapat dicatat, karena sudah "secepat dapat diamati".

Namun dalam konsumsi energi perangkat seluler merupakan faktor penting. Handler acara yang sama yang dioptimalkan untuk berjalan sepuluh persen lebih cepat akan menghasilkan lebih sedikit energi yang dikonsumsi dan itu lebih tahan baterai dan perangkat yang beroperasi lebih lama.

Seberapa akurat penilaian terakhir tentang perangkat seluler? Adakah contoh kehidupan nyata yang mengonfirmasi atau membantahnya?


3
IMHO, seperti halnya optimasi secara umum, Anda hanya bisa mendapatkan jawaban yang andal melalui pengukuran. Namun pertanyaannya bagus, +1 :-)
Péter Török

1
Tentukan persyaratan Anda. Saya mendapat kesan bahwa Anda berbicara tentang optimasi mikro runtime, dan Anda secara khusus menyebutkan penggunaan energi, tetapi dalam konteks perangkat kecil itu bukan satu-satunya hal yang mungkin layak dioptimalkan. Ukuran dan jejak memori yang dapat dieksekusi adalah yang lain.
Peter Taylor

Jawaban:


12

Ini layak jika pengukuran mengatakan itu layak. Untuk perangkat seluler maupun superkomputer.

EDIT: Sedikit topik, tapi tentang contoh Anda. Jika peristiwa itu dipicu berkali-kali, maka Anda memiliki masalah konsepsi, dan menyelesaikan masalah konsepsi itu adalah masalah nyata. Tidak membuatnya kurang terlihat dengan mengoptimalkan mikro.

Anda dapat melakukan tes di callback misalnya, untuk membuang terlalu sering panggilan, atau mengerjakan ulang cara panggilan balik dipanggil.

Secara umum, itu adalah praktik yang buruk untuk melampirkan panggilan balik ke «acara yang berkelanjutan». Maksud saya, peristiwa yang tidak memicu sekali dan kemudian dilakukan, tapi itu memicu tindakan yang berlangsung dari waktu ke waktu.

Menggulir halaman atau slider, misalnya, adalah peristiwa yang berkelanjutan.

Anda tidak pernah tahu berapa kali peristiwa itu akan dipicu. Jika mereka terpicu cukup cepat, aplikasi Anda menjadi lamban, dan jika dipicu terlalu banyak, Anda akan berakhir dengan beban CPU yang sangat besar tanpa hasil, berpotensi membuat aplikasi Anda terlalu lambat.


Oke, apa yang saya ukur - Konsumsi daya atau apa pun?
sharptooth

4
Ukur apa yang penting bagi pengguna Anda. Jika konsumsi merupakan masalah (dan itu ada di perangkat seluler) maka ukurlah, dan bertindak sesuai dengan pengukuran.
deadalnix

Bagaimana dengan pertimbangan komersial - apakah menguntungkan untuk melakukan optimasi? Baterai yang lebih besar mungkin lebih murah daripada waktu rekayasa untuk produk volume menengah ke bawah. Antarmuka pengguna yang lebih lambat dengan usia baterai 5% lebih sedikit lebih baik daripada tidak ada produk di pasar. Sangat mudah untuk membakar $$$ dan tidak pernah mencapai kesempurnaan.
mattnz

2

Seberapa akurat penilaian terakhir tentang perangkat seluler?

Ini hanya seakurat pengukuran aktual pada perangkat aktual yang benar-benar menunjukkan bahwa optimasi sebenarnya akan membantu.

Asumsi dan penilaian tidak berharga.

Pengukuran memiliki nilai.

Semua optimisasi (termasuk "optimasi mikro", apa pun itu) adalah buang-buang waktu sampai ada pengukuran aktual yang menunjukkan masalah aktual di mana kode sebenarnya gagal memenuhi beberapa persyaratan (untuk kecepatan, memori, daya, atau latensi jaringan atau apa pun ).


2

(Dengan asumsi kecepatan adalah masalah utama Anda.) Semua orang benar.
Kecuali - pengukuran tidak akan memberi tahu Anda apa yang harus dioptimalkan.

Pengukuran akan memberi tahu Anda bahwa Anda perlu mengoptimalkan.
Pengukuran akan memberi tahu Anda berapa banyak yang Anda simpan saat Anda mengoptimalkan.

Pengukuran tidak akan memberi tahu Anda apa yang harus dioptimalkan.
Teknik ini akan memberi tahu Anda apa yang harus dioptimalkan.


2
Bukankah membuat profil lebih baik daripada teknik pengambilan sampel acak ini?
S.Lott

2
@ S.Lott q: apakah melihat mural dari dua blok lebih baik daripada melihatnya dari jarak dua kaki? a: Anda benar-benar tidak melihat mural jika dilihat dari perspektif tunggal. keduanya penting. pengambilan sampel / pembuatan profil dapat menjadi pemborosan waktu jika hanya itu perspektif yang Anda ambil untuk mengevaluasi kinerja program Anda.
justin

@Justin: "pengambilan sampel / pembuatan profil dapat membuang waktu jika ..."? Apa? Anda memberikan tautan tentang pengambilan sampel, seolah-olah profil tidak sebagus pengambilan sampel. Sekarang Anda mengatakan keduanya berpotensi buruk? Apa pilihan ketiga, berbeda dari pengambilan sampel di tautan dan pembuatan profil (yang tampaknya lebih lengkap dan bermanfaat bagi saya)? Jika ada pilihan ketiga, dapatkah Anda memperbarui jawaban Anda untuk menjelaskan bagaimana semua pilihan ini cocok? Saya masih tidak jelas tentang apa yang salah dengan pembuatan profil. Tautan tidak menjelaskan mengapa pengambilan sampel lebih baik.
S.Lott

@ S.Lott: Ya saya tahu itu pandangan minoritas, tetapi sejumlah orang telah mencobanya dan setuju. Jika saya bisa membuat analogi, arkeolog menggunakan alat-alat tangan dan sikat, karena detail halus itu penting, dan mereka perlu memahaminya. Satu-satunya profiler yang saya tahu yang dekat adalah Zoom . Dan jika Anda mencobanya Anda akan melihatnya masih sangat berbeda, karena berkonsentrasi pada pemahaman . Ini metode yang digunakan di sini .
Mike Dunlavey

@ Mike Dunlavey: "sudah mencobanya dan setuju"? Apa itu? Contoh? Pembuatan profil? Atau apa pun pilihan ketiga adalah ketika "pengambilan sampel / profil dapat menjadi buang waktu jika ..."? Apakah Anda mengatakan pembuatan profil berfungsi? Atau profil membutuhkan alat khusus?
S.Lott

1

Saya kenal dengan optimasi. saya melihat program orang lain dengan pandangan berbeda - inilah pendapat saya:

Biasanya optimasi mikro dianggap tidak layak dengan penjelasan berikut: mungkin mempercepat program kurang dari satu persen, tetapi tidak ada yang peduli dengan dorongan kecil itu - itu hanya sedikit perubahan yang harus diperhatikan.

lucunya, satu perubahan seperti itu menghasilkan 99% sepuluh perubahan semacam itu membuat program lebih cepat terlihat. bagi banyak insinyur, perubahan pada pendekatan mereka dalam menulis suatu program dapat membuat suatu program mengeksekusi beberapa kali lebih cepat. hanya dengan menyadari efisiensi dan menulis seperti itu dapat membuat program Anda beberapa kali lebih cepat tanpa banyak pekerjaan tambahan. keuntungan seperti itu bukan optimasi mikro, imo.

Catatan: saya tidak pernah menyarankan optimisasi sudut tajam dalam diskusi ini.

Selain itu, mungkin ada beberapa event handler yang menyala seribu kali per detik dan keluar dengan sangat cepat - sebelum dipecat lagi. Tidak ada yang peduli seberapa cepat itu - membuatnya lebih cepat tidak dapat dicatat, karena sudah "secepat dapat diamati".

dan kemungkinan sudah melakukan lebih banyak pekerjaan daripada yang diperlukan karena 1kHz jauh lebih tinggi daripada banyak kasus membutuhkan. apa sumber event handler ini, dan apa pengaruhnya? jika hanya memperbarui UI dan acara dapat dikumpulkan dan digabungkan, maka pengiriman 1kHz tentu saja berlebihan (jauh lebih dari 1% - lebih seperti 25x). untuk sistem yang memiliki sumber mulitple dan ditransmisikan secara serial, maka 1kHz mungkin tidak cukup cepat (misalnya MIDI).

Namun dalam konsumsi energi perangkat seluler merupakan faktor penting. Handler acara yang sama yang dioptimalkan untuk berjalan sepuluh persen lebih cepat akan menghasilkan lebih sedikit energi yang dikonsumsi dan itu lebih tahan baterai dan perangkat yang beroperasi lebih lama. Seberapa akurat penilaian terakhir tentang perangkat seluler? Adakah contoh kehidupan nyata yang mengonfirmasi atau membantahnya?

berdasarkan pada program yang saya lihat, tidak banyak orang yang mempertimbangkan (atau peduli dengan) optimasi semacam itu, meskipun mengubah pendekatan Anda pada program penulisan dapat menghasilkan keuntungan luar biasa (> 10x atau lebih cepat). banyak yang telah saya lihat (di sisi pengembangan aplikasi) hanya menulis lalu mengambil pendekatan top down atau "hail mary" ketika (/ jika) masalah kinerja menyusul mereka. sama halnya, banyak yang bahkan tidak akan meluangkan waktu untuk profil sampai kejadian seperti itu. pada saat itu, kebisingan dari begitu banyak inefisiensi senyawa membuatnya sangat sulit untuk mendapatkan informasi yang berguna dari seorang profiler. contoh pendekatan hujan es akan mengoptimalkan area yang salah (dengan atau tanpa mencari area masalah), atau hanya melempar lebih banyak core pada area masalah; ini terjadi daripada memperbaiki inefisiensi yang ada.

untuk program yang sudah ada (di antara program seluler yang telah saya lihat), pengoptimalan bukan masalah besar ketika ditulis. jadi "ya" mereka (dalam kasus khas) sepadan dengan waktu, asalkan itu dalam anggaran dan prioritas. dalam hal itu, sepuluh perubahan yang membuat program lebih cepat terlihat dapat dilakukan dalam beberapa jam, dan kurang dari sehari.

"menulis dengan malas dan profil dalam retrospeksi" sebagai satu-satunya tindakan untuk meningkatkan program adalah ide yang mengerikan: meluangkan waktu untuk belajar bagaimana menulis program yang efisien (seperti yang tertulis, bukan dengan menyatukannya di akhir) adalah yang terbaik pendekatan (imo); gunakan algoritma yang tepat, melarang penyalinan yang sia-sia, alokasi, perhitungan (+ banyak, banyak kategori lainnya). tentu saja, menganalisis kinerja dalam retrospeksi memiliki kelebihan, tetapi jika Anda menulis program menjadi efisien sejak awal, Anda akan memiliki tingkat efisiensi yang sama sekali baru karena Anda belajar banyak dan mempertimbangkan serta mengevaluasi pelaksanaan dari berbagai perspektif.

yang lain adalah bahwa program harus (sering) ditulis untuk digunakan kembali, program yang ditulis dengan buruk akan memperkenalkan perubahan yang dapat merusak program klien ketika inefisiensi dihapus (atau hanya tetap tidak efisien untuk menghindari melanggar program yang ada).

satu manfaat besar dari mempertimbangkan ketika Anda menulis adalah bahwa Anda memiliki ide yang sangat jelas tentang bagaimana program akan beroperasi (walaupun bukan gambaran lengkap), Anda dapat menggunakan informasi ini untuk membantu dalam desain antarmuka dan bagaimana menyimpan datanya. . sebenarnya, seorang insinyur dapat mengimplementasikan sesuatu yang beberapa (misalnya> 10x) kali lebih cepat daripada solusi standar "satu ukuran cocok untuk semua" yang disediakan dengan OS.

akhirnya, itu juga sangat berharga di luar perangkat seluler. ada banyak program yang tidak efisien di luar sana, ditulis dengan pola pikir bahwa perangkat keras akan lebih cepat dalam dua tahun (sering rasional, bahkan untuk program yang ditulis hari ini!). sementara itu tidak salah , itu terlalu optimis. juga, paralelisasi memiliki tujuan tetapi itu adalah "solusi default" yang salah untuk banyak program. banyak dari program yang ada ini dapat diperbaiki dengan terlebih dahulu menghilangkan ketidakefisienan yang ada.

jadi ... biasanya ada satu ton dari kasus-kasus 1%, 2%, 7% (dan jauh lebih buruk) di dunia nyata. memperbaikinya atau (yang lebih penting) tidak menulis / memaparkannya dapat memberikan manfaat besar. banyak dari kasus-kasus tersebut dapat dengan mudah ditemukan dan diperbaiki (asalkan insinyur memiliki pengalaman dengan ini). Namun, itu bisa sangat menyebalkan untuk mengoreksi dan menguji ulang setelah fakta. jika sebuah program ingin optimal, idealnya akan ditulis seperti itu sejak awal.

sebagai pengguna akhir, sangat menjengkelkan untuk terus menunggu program lambat dan melemparkan dua kali perangkat keras pada masalah yang diciptakan oleh program lambat / tidak efisien: T: "apa yang akan Anda lakukan sekarang karena Anda memiliki dua kali inti dan dua kali memori?" A: "mendapatkan kembali daya tanggap dan produktivitas yang saya miliki sebelum saya meningkatkan perangkat lunak saya - itu saja". cukup tidak pengertian dari pengembang (imho).


1
Meluangkan waktu untuk menyempurnakannya merupakan kemewahan yang bagus bagi sebagian orang. Satu perusahaan yang saya tahu tentang usaha mikro yang dioptimalkan untuk keluar dari bisnis. Produk pesaing mereka lebih rendah dalam segala hal, lebih lambat dan perlu diisi ulang lebih sering da da da, tetapi mungkin bagi pengguna untuk membeli satu dengan harga yang pengguna siap membayar .....
mattnz

@ mattnz contoh yang adil (+1). sebagai catatan, saya tidak membuat kasus untuk program yang sempurna. posting saya menekankan desain yang baik dengan penekanan yang lebih tinggi dan pertimbangan untuk kinerja daripada yang khas. dalam pertahanan biaya: Anda sering dapat menemukan keseimbangan yang baik antara program yang ditulis dengan baik yang berkinerja baik dengan komponen yang dapat digunakan kembali dengan mudah versus desain yang buruk / tidak efisien yang akhirnya memiliki masa hidup yang relatif singkat. seseorang harus memperhitungkan biaya perawatan dan mengenali kekuatan dan kelemahan masing-masing desain. (lanjutan)
justin

(lanjutan) implementasi yang baik cenderung dapat digunakan kembali dan berumur panjang sementara program yang ditulis dengan buruk menghadapi keusangan lebih cepat dan seringkali memerlukan biaya pemeliharaan yang tinggi (mis. debugging, tuning, penulisan ulang, pengujian ulang sebelum dan setelah pengiriman). program yang ditulis dengan buruk seringkali merupakan pemborosan waktu / sumber daya pembangunan dalam jangka panjang.
justin

1

Alasan mengapa Anda tidak perlu repot-repot dengan optimasi mikro adalah karena mereka optimasi mikro . Anda harus melihat gambar yang lebih besar dan bukannya membuang waktu Anda pada optimasi mikro , cari alasan untuk perbaikan nyata .

Aturan praktis saya adalah bahwa setiap kode yang ditulis tanpa memperhatikan kecepatan, tetapi tidak sepenuhnya bodoh juga, dapat dibuat sepuluh kali lebih cepat dengan banyak upaya. 10% melalui mikro-optimisasi bukanlah sesuatu yang akan saya pedulikan. Saya yakin Anda bisa menghemat lebih banyak dari itu, dengan sedikit usaha.

Di sisi lain, dalam produk komersial dalam beberapa tahun terakhir, "optimasi" bagi saya sebagian besar terdiri dari menemukan kode yang membuang waktu, dan tidak menyia-nyiakannya. Lebih banyak tidak pesimis daripada optimisasi.

(Di sisi lain, beberapa orang melekat di otak mereka bahwa optimasi prematur itu jahat, jadi jika ada satu cara A untuk melakukan sesuatu dan cara B yang kurang efisien, mereka akan memilih B karena A adalah "optimasi prematur" (Beberapa orang bodoh).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.