makepp_speedup - Online di Cloud

PROGRAM:

NAMA

makepp_speedup -- Cara membuat makepp lebih cepat

DESKRIPSI

Jadi menurutmu makepp lambat? Sudah terasa lebih cepat, tapi memang begitu, tetap saja
lambat, terutama jika Anda berasal dari GNU make. Ini karena ia dengan cermat memeriksa semua
hal-hal di mana gmake membuat Anda sakit kepala, mengabaikan banyak dependensi ("Saya pikir
Saya perlu gmake clean untuk menyingkirkan sindrom bug misterius"). Jika Anda mencurigai beberapa Perl
kode yang Anda tambahkan ke makefile Anda mungkin salah, lihat perl_performance.

Tetapi ada beberapa hal yang dapat Anda lakukan untuk memeras lebih banyak kecepatan. Beberapa hal tersebut adalah
berlabel tidak aman, dalam artian Anda meminta makepp untuk tidak memeriksa atau melakukan hal-hal tertentu,
yang menurut Anda tidak diperlukan. Jika hal-hal ini diperlukan, bangunan mungkin
tidak benar. Untungnya masalah ini akan bersifat sementara. Ini akan diperbaiki
segera setelah Anda membiarkan makepp melakukan semua pemeriksaan.

Anda dapat menggabungkan beberapa tips ini untuk meningkatkan perolehan waktu lebih banyak lagi.

Aman metode
penggunaan makepreplay

Utilitas makeppreplay yang berdiri sendiri, mppr mengulangi hal-hal yang telah dilakukan makepp,
tanpa overhead apapun.

penggunaan a Lebih cepat Perl

Dalam versi 5.8, semuanya kurang lebih sama, hanya 5.8.7 sedikit lebih cepat. Menyetel Anda
Perl juga dapat membantu, seperti tidak mengompilasinya untuk 64 bit, yang tidak diperlukan makepp. Untuk
contoh build ActiveState (http://www.activestate.com/activeperl>) dari 5.8.7 untuk Linux
lebih cepat dari Perl 5.8.7 yang datang dengan SuSE Linux 10.0.

Memasukkan as Sedikit as Mungkin

Setiap file tambahan yang Anda sertakan akan dikenakan sanksi ganda. Di satu sisi, kompiler harus
cari dan lihat semua file itu. Anda tidak terlalu memperhatikan ini, karena itu hanya
sedikit tambahan per panggilan kompiler. Di sisi lain makepp harus mencari juga, untuk menemukan
dependensi dan mencari tahu apakah mereka mengalami pembangunan kembali. Kemudian sepertinya macet,
sementara itu mencerna banyak dependensi sekaligus.

Varian yang benar-benar mematikan adalah master proyek termasuk file, yang pada gilirannya
dengan mudah mencakup apa pun yang mungkin Anda butuhkan. Hasilnya adalah bahwa setiap file header berubah
mengarah ke pembangunan penuh. Bahkan tanpa perubahan, makepp harus memikirkan semua header itu
sekali lagi, untuk setiap sumber yang Anda kompilasi. Hanya upaya kecil, karena ini di-cache, tapi
ribuan file dapat membuat ini mengejutkan.

Mungkin rumit untuk mengetahui set minimal termasuk, dan untuk membersihkan yang tidak ada
lagi dibutuhkan, tapi itu benar-benar terbayar. Jika ada yang tahu alat yang dapat mengidentifikasi mana
file disertakan tidak perlu, saya akan senang untuk menyebutkannya di sini!

Membangun as Sedikit as Kamu Perlu

Jika Anda memiliki target default yang membuat beberapa program, maka makepp harus memeriksa
semua dependensinya, sampai ke file header terkecil. Tapi mungkin kamu mau
uji perubahan Anda hanya dengan salah satu program tersebut.

Kemudian Anda akan memanggil makepp dengan target eksplisit. Semakin sedikit modul atau tajuk semua itu
program memiliki kesamaan, semakin besar manfaat dari tidak membiarkan makepp memeriksa semuanya.

Katakanlah Makeppfile tingkat atas Anda memiliki aturan ini:

$(semua palsu): proggie1 proggie2 $(only_phony_targets */**/all)

Maka Anda akan memanggil hal-hal seperti

$makepp proggie2
$ makepp proggie1 dir/subdir/proggie27

penggunaan disukai makefile nama

Makepp mencari makefile (kecuali jika Anda menentukannya secara eksplisit pada baris perintah atau dengan
"muat-makefile") dalam urutan File RootMakepp, RootMakeppfile.mk, File Makepp dan
Makeppfile.mk, diikuti dengan nama makefile klasik. (NS .mk varian adalah untuk murni
sistem berbasis akhiran.)

Jadi, jika Anda menggunakan File RootMakepp di akar pohon bangunan Anda, dan File Makepp di mana-mana
jika tidak, file akan ditemukan sedikit lebih cepat. Makepp juga akan memiliki sedikit lebih kecil
konsumsi memori (menyimpan fakta bahwa nama lain tidak ada), yang juga berarti
kecepatan melalui manajemen memori yang lebih sedikit.

Demikian juga jika Anda memiliki pernyataan

termasuk standar

pertama-tama akan ada upaya untuk menemukan standar.makepp, jadi kamu mungkin juga menggunakannya
Nama.

Memiliki as beberapa aturan as Anda perlu

Makepp melacak tidak hanya file yang ada, tetapi juga semua yang dipelajarinya untuk dibuat.
(Itulah mengapa ia menawarkan wildcard yang andal seperti *.Hai.) Harga untuk kekuatan ini banyak
pengelolaan. Jadi, jika Anda memberi tahu cara membuat .o dari .c, tidak apa-apa, karena itu akan
terjadi untuk sebagian besar jika tidak semua kandidat.

Tetapi jika Anda memberi tahu cara menautkan apa pun yang dapat dieksekusi tanpa akhiran dari nama yang serupa .o, itu
mahal, karena itu mungkin hanya akan terjadi pada sebagian kecil dari mereka (yang
mengandung fungsi utama), tetapi dasarnya akan diletakkan untuk semua. Anda harus menimbang
kenyamanan aturan pola linker, bertentangan dengan efisiensi aturan linker individu.

Jika Anda tidak menggunakannya, Anda juga harus mematikan aturan bawaan dengan:

makepp_no_builtin = 1

Jika Anda menggunakannya, tetapi, untuk alasan yang dijelaskan di atas, bukan aturan tautan bawaan,
Anda harus mematikannya dengan:

makepp_no_builtin_linker = 1

Menempatkan makepp ekstensi ke a modul

Makepp menawarkan kemungkinan yang sangat nyaman untuk diperpanjang melalui Perl. Tapi jika kamu
tulis beberapa fungsi, perintah, atau pernyataan dalam file dan sertakan itu dari lusinan
makefiles, Anda akan mendapatkan lusinan salinan semuanya di memori. Dan mereka akan dibaca
puluhan kali oleh parser makepp, yang sedikit lebih lambat dari Perl.

Dalam situasi ini lebih baik untuk menempatkan fungsi Anda sendiri ke dalam modul.

penggunaan Repositori dan / atau a Membangun Cache

Jika Anda memiliki beberapa pengembang yang bekerja pada mesin yang sama atau jika Anda mengubah ke sana kemari
antara set opsi build, ini untuk Anda. Repositori memungkinkan Anda untuk menawarkan pusat
referensi di mana Anda hanya perlu membangun apa yang berbeda secara lokal. Cache build secara sederhana
mengumpulkan semua file yang dihasilkan, dan menggunakannya kembali sebagaimana mestinya, dengan perencanaan yang lebih sedikit.
Halaman terakhir juga menjelaskan perbedaannya.

penggunaan Kotak pasir

Jika build Anda sangat besar sehingga makepp kesulitan mencerna semua informasi
dan jika Anda dapat menemukan cara untuk membaginya menjadi bagian-bagian independen yang lebih kecil, kotak pasir
mungkin memberi Anda paralelisme yang lebih baik daripada opsi "--jobs".

Jangan mencatat apa Anda do

Fitur logging Makepp sangat kuat untuk melacak bug di sistem build, atau
untuk menganalisis dependensi Anda. Setiap kali Anda tidak melakukan hal-hal ini, Anda dapat menghemat cukup banyak
sedikit pemformatan dan I/O dengan "--no-log --no-scan-log".

Hampir Aman metode
Dapatkan a Mulai dari awal

Opsi "--loop" (atau "--stop-before-building" atau "--stop-after-loading" atau "--stop")
memungkinkan makepp untuk memulai pekerjaannya saat Anda masih mengedit. Ini akan berulang kali ditangguhkan
sendiri ketika sampai pada titik menganalisis dependensi. Anda memutuskan kapan Anda siap
untuk membiarkannya berlanjut. Pada proyek besar kami, ini menghemat setengah menit, dan hanya saat itulah kami
memiliki CPU untuk diri kita sendiri.

Metode ini memiliki dua kelemahan potensial:

· Makeppfiles telah dibaca pada saat makepp berhenti. Jika Anda mengedit Makeppfile atau
sesuatu yang harus dibangun kembali, setelah memulai makepp, ini akan berjalan
tanpa disadari sampai waktu berikutnya. Tapi ini jarang diperlukan, karena makepp
sangat mengurangi kebutuhan akan perubahan Makeppfile.

· Jika target bergantung pada wildcard, dan itu akan lebih cocok daripada saat Makeppfile
dibaca, makepp tidak akan memperhatikan:

program: *.o
$(LD) $(masukan) -o $(keluaran)

Jika Anda menambahkan file sumber lain, atau file dari mana makepp tahu cara menghasilkan a
source, maka "*.o" harus cocok dengan objek yang dihasilkan. Tapi, jika file ini ditambahkan
setelah memulai makepp, itu tidak akan terjadi, karena wildcard diperluas terlalu dini.

Dalam kedua kasus ini, Anda harus mematikan makepp yang telah dimulai sebelumnya dan memulainya lagi.

Gulliver's Perjalanan

Opsi "--gullible" memberi tahu makepp untuk percaya bahwa aturan mengubah apa yang dikatakannya,
tidak kurang dan tidak lebih. Tidak melakukan pemeriksaan ini dapat menghemat beberapa persen dari CPU makepp
waktu. Dan penghematan Disk I/O sangat diterima di sistem file jaringan. Jika kamu melakukan
nightly full build di direktori kosong dengan opsi "--repository", tetapi tanpa
opsi "--gullible", Anda cukup yakin bahwa kumpulan aturan Anda konsisten. Lalu ini
pilihan seharusnya tidak ada salahnya dalam pekerjaan siang hari Anda.

Berpotensi Tidak aman metode
Metode ini tidak aman jika Anda memberikan petunjuk yang salah kepada makepp. Tapi semuanya akan kembali lagi
baiklah, namun, segera setelah Anda membiarkan makepp melakukan semua pemeriksaan, dengan tidak memberikan batasan apa pun
pilihan. Untuk alasan ini saya sarankan menggunakan petunjuk ini untuk mendapatkan build perantara cepat,
dan gunakan waktu makan siang dan malam untuk membiarkan makepp melakukan tugasnya secara menyeluruh.

Membangun as Sedikit as Dibutuhkan

Ini adalah tip yang sama dalam menggunakan target eksplisit yang dibahas di bawah "Bangun Sesedikit Anda
Perlu" di atas. Tetapi menjadi lebih berbahaya, jika Anda melakukannya karena Anda yakin bahwa Anda
perubahan tidak akan mempengaruhi program lainnya. Maka mereka tidak akan dibangun, bahkan
meskipun itu mungkin diperlukan.

Tahu Where Tidak untuk Membangun

Opsi "--dont-build" sangat kuat untuk mempercepat makepp banyak. Jika Anda tahu satu
atau lebih direktori, yang Anda yakin tidak terpengaruh oleh perubahan apa pun yang Anda buat sejak
terakhir kali, Anda dapat mengeluarkan opsi "--dont-build" untuk mereka. Ini bisa menghemat banyak makepp
analisis ketergantungan. Tapi itu tidak akan membangun apa pun di direktori itu, bahkan jika itu
harus punya.

Tahu Where untuk Membangun

Ini sama dengan "Tahu di mana tidak membangun", tetapi alih-alih daftar pengecualian, Anda
menyediakan daftar inklusi. Triknya adalah opsi "--do-build", dengan a
"--dont-build=/" atau di bawah direktori "RootMakeppfile(.mk)" tanpa
Opsi "--dont-build" pada direktori tingkat yang lebih tinggi berarti: tidak membangun apa pun kecuali apa yang saya katakan
kamu juga. Inilah yang dicari oleh pengguna merek tradisional ketika mereka ingin membangun
hanya satu direktori:

$ makepp --do-build=dir/subdir

atau, jika Anda tidak memiliki "RootMakeppfile(.mk)":

$ makepp --dont-build=/ --do-build=dir/subdir

Perbedaannya adalah bahwa setiap target default di Makeppfile tingkat atas, yaitu perintah tautan
juga dieksekusi dengan cara ini. Jika Anda tidak menginginkannya, Anda harus memberikan target yang jelas,
yang secara otomatis juga ditandai untuk "--do-build":

$ makepp --do-build=dir1/subdir dir2/proggie

Tahu Apa untuk Membangun

Varian ekstrim meminta makepp untuk tidak membangun apa pun kecuali apa yang Anda perintahkan. Ini
tidak begitu berbahaya jika kamu berubah tidak memasukkan arsip, hanya modul, dan Anda tahu yang mana
program yang mereka masuki.

Katakanlah Anda hanya mengubah "src/a.cpp" dan "src/b.cpp" dan ini terhubung langsung ke
satu program. Dot adalah direktori saat ini termasuk semua subdirektori.

$ makepp --dont-build=. src/ao src/bo proggie1

Atau yang setara, karena opsi "--do-build", tanpa opsi "--dont-build" pada
direktori tingkat yang lebih tinggi menyiratkan "--dont-build" untuk root dari pohon build:

$ makepp --do-build=src/ao src/bo proggie1

Anda dapat melakukan sesuatu seperti berikut ini di file $ENV atau .profile Shell Anda untuk menyimpan
mengetik (pengguna csh mengganti '=' dengan ' '):

alias mppb='makepp --do-build'
alias mppsb='makepp --stop --do-build'

Maka contoh terakhir menjadi:

$ mppb src/ao src/bo proggie1

Membangun on a RAM cakram

Komputer modern, terutama server, biasanya memiliki waktu rata-rata yang tinggi antara kegagalan. Jika
ini adalah kasus untuk Anda, dan Anda memiliki banyak RAM yang tersisa, Anda dapat menghemat waktu Anda
menunggu I/O. Anda harus mengedit pada disk nyata, atau mereplikasi pengeditan Anda di sana dengan cepat. Tetapi
hasil build dapat direproduksi, sehingga dapat berada di RAM. Jika Anda tidak ingin mengambil risiko
membangun kembali, Anda selalu dapat mereplikasi ke disk setelah setiap pembuatan atau di malam hari. Anda tidak harus
lakukan ini selama pembuatan, karena Anda mungkin menangkap sebagian file yang ditulis, sama seperti jika
mesin telah jatuh.

Jika Anda memiliki sistem dan/atau unit penyimpanan dengan caching dan RAID yang baik, perolehannya mungkin tidak
begitu besar.

Gunakan makepp_speedup online menggunakan layanan onworks.net