Mengapa require_once begitu buruk untuk digunakan?


143

Semua yang saya baca tentang praktik pengkodean PHP yang lebih baik terus mengatakan jangan gunakan require_once karena kecepatan.

Kenapa ini?

Apa cara yang tepat / lebih baik untuk melakukan hal yang sama require_once? Jika itu penting, saya menggunakan PHP 5.


9
Pertanyaan ini sudah cukup lama sekarang, dan jawabannya tidak relevan lagi. Alangkah
baiknya

Jawaban:


108

require_oncedan include_oncekeduanya mengharuskan sistem menyimpan log dari apa yang sudah termasuk / diperlukan. Setiap *_oncepanggilan berarti memeriksa log itu. Jadi pasti ada beberapa pekerjaan tambahan yang dilakukan di sana tetapi cukup untuk merusak kecepatan seluruh aplikasi?

... Aku benar-benar ragu itu ... Tidak, kecuali Anda berada di benar-benar hardware lama atau melakukan itu banyak .

Jika Anda sedang melakukan ribuan *_once, Anda bisa melakukan pekerjaan sendiri dengan cara yang lebih ringan. Untuk aplikasi sederhana, hanya memastikan Anda hanya disertakan sekali harus cukup tetapi jika Anda masih mendapatkan kesalahan mendefinisikan kembali, Anda bisa sesuatu seperti ini:

if (!defined('MyIncludeName')) {
    require('MyIncludeName');
    define('MyIncludeName', 1);
}

Saya pribadi akan tetap dengan *_oncepernyataan tetapi pada patokan juta pass konyol, Anda dapat melihat perbedaan antara keduanya:

                php                  hhvm
if defined      0.18587779998779     0.046600103378296
require_once    1.2219581604004      3.2908599376678

10-100 × lebih lambat dengan require_oncedan anehnya require_oncetampaknya lebih lambat hhvm. Sekali lagi, ini hanya relevan dengan kode Anda jika Anda menjalankan *_onceribuan kali.


<?php // test.php

$LIMIT = 1000000;

$start = microtime(true);

for ($i=0; $i<$LIMIT; $i++)
    if (!defined('include.php')) {
        require('include.php');
        define('include.php', 1);
    }

$mid = microtime(true);

for ($i=0; $i<$LIMIT; $i++)
    require_once('include.php');

$end = microtime(true);

printf("if defined\t%s\nrequire_once\t%s\n", $mid-$start, $end-$mid);

<?php // include.php

// do nothing.

29
Saya ragu metode Anda didefinisikan () lebih cepat dari tabel pencarian built-in, tapi saya setuju dengan poin keseluruhan Anda - pasti bukan masalah ?!
Bobby Jack

1
Saya cukup yakin Anda benar, Bobby, tetapi saya tidak menganjurkan penetapan lebih dari satu kali. Itu hanya sebuah pilihan. Waktu yang diperlukan untuk menginterpretasikan kode mungkin bahkan membuatnya sedikit lebih lambat, tetapi, yang mengatakan, saya tidak tahu seberapa teliti metode internal itu. Mungkin perlu kerja ekstra untuk memastikan tidak ada duplikat.
Oli

8
Kelemahan lainnya adalah APC tidak
men-

3
Saya baru saja melakukan tes yang sangat mendasar dari kedua metode - saya melakukan 1.000.000 iterasi termasuk file yang hanya mendefinisikan 'testinclude' yang konstan menjadi true. Dalam tes pertama, saya menggunakan require_once, yang kedua saya gunakan jika (! Didefinisikan ('testinclude')) dan hasilnya menarik: Membutuhkan: 0,81639003753662 Tidak Didefinisikan: 0,17906713485718 Didefinisikan adalah 0,63732290267944 mikrodetik lebih cepat.
Travis Weston

Kasing dengan define akan lebih cepat karena Anda tidak melakukan pemeriksaan tambahan apa pun seperti menggunakan realpath. Itu tidak membandingkan dua hal yang benar-benar sama.
jgmjgm

150

Utas ini membuat saya merasa ngeri, karena sudah ada "solusi yang diposting", dan itu, untuk semua maksud dan tujuan, salah. Mari kita hitung:

  1. Definisinya sangat mahal di PHP. Anda dapat mencarinya atau mengujinya sendiri, tetapi satu-satunya cara efisien mendefinisikan konstanta global dalam PHP adalah melalui ekstensi. (Konstanta kelas sebenarnya kinerja yang lumayan bijaksana, tapi ini adalah poin yang diperdebatkan, karena 2)

  2. Jika Anda menggunakan dengan require_once()tepat, yaitu, untuk memasukkan kelas, Anda bahkan tidak perlu mendefinisikan; periksa saja apakah class_exists('Classname'). Jika file yang Anda sertakan berisi kode, yaitu Anda menggunakannya dengan cara prosedural, sama sekali tidak ada alasan yang require_once()harus diperlukan untuk Anda; setiap kali Anda memasukkan file yang Anda anggap melakukan panggilan subrutin.

Jadi untuk sementara, banyak orang yang menggunakan class_exists()metode ini untuk inklusi mereka. Saya tidak suka karena ini jelek, tetapi mereka punya alasan bagus untuk: require_once()cukup tidak efisien sebelum beberapa versi PHP yang lebih baru. Tapi itu sudah diperbaiki, dan menurut pendapat saya bahwa bytecode tambahan yang harus Anda kompilasi untuk kondisional, dan panggilan metode tambahan, akan jauh melebihi pemeriksaan hashtable internal apa pun.

Sekarang, sebuah pengakuan: hal ini sulit untuk diuji, karena hanya menyumbang sedikit waktu eksekusi.

Berikut adalah pertanyaan yang harus Anda pikirkan: termasuk, sebagai aturan umum, mahal dalam PHP, karena setiap kali penerjemah menemukan satu harus beralih kembali ke mode parse, menghasilkan opcodes, dan kemudian melompat kembali. Jika Anda memiliki 100+ termasuk, ini pasti akan memiliki dampak kinerja. Alasan mengapa menggunakan atau tidak menggunakan require_once adalah pertanyaan yang sangat penting adalah karena ini membuat susah untuk cache opcode. Sebuah penjelasan untuk ini dapat ditemukan di sini, tapi apa ini intinya adalah bahwa:

  • Jika selama parse time, Anda tahu persis apa yang termasuk file yang akan Anda butuhkan untuk seluruh umur permintaan, require()yang di awal dan cache opcode akan menangani semua yang lain untuk Anda.

  • Jika Anda tidak menjalankan opcode cache, Anda berada di tempat yang sulit. Memasukkan semua menyertakan Anda ke dalam satu file (jangan lakukan ini selama pengembangan, hanya dalam produksi) pasti dapat membantu mengurai waktu, tetapi itu menyebalkan untuk dilakukan, dan juga, Anda perlu tahu persis apa yang akan Anda sertakan selama permintaan.

  • Autoload sangat mudah, tetapi lambat, dengan alasan bahwa logika autoload harus dijalankan setiap kali menyertakan. Dalam praktiknya, saya telah menemukan bahwa autoloading beberapa file khusus untuk satu permintaan tidak menyebabkan terlalu banyak masalah, tetapi Anda seharusnya tidak autoloading semua file yang Anda perlukan.

  • Jika Anda memiliki 10 termasuk (ini adalah bagian paling belakang dari perhitungan amplop), semua wanking ini tidak sepadan: hanya mengoptimalkan permintaan basis data Anda atau sesuatu.


14
Ini berumur 4 tahun dan sebagian besar tidak berlaku lagi define(), require_once()dan defined()semua memakan waktu sekitar 1-2 mikrodetik pada komputer saya.
Daniel Beardsley

72
Tapi itu 2 mikrodetik lebih cepat pengguna akan memiliki halaman. Lebih dari setahun tampilan halaman, itu bisa menghemat pengguna 3 detik penuh! Mereka bisa menonton sepersepuluh iklan pada waktu itu! Pikirkan pengguna. Jangan sia-siakan mikrodetik.
Andrew Ensley

15
Supaya semua orang menyadari sarkasme, mikrodetik adalah 1/1000000 per detik.
Andy Chase

1
@AndrewEnsley Anda salah dengan semua sarkasme Anda. Anda tidak tahu tentang fakta bahwa PHP juga berjalan pada mikroprosesor, 1 mikrodetik pada PC Anda beberapa milidetik pada mikroprosesor. Sekarang bagaimana dengan memiliki 20 file sertakan, proyek yang lebih besar? Itu 20 kali keterlambatan beberapa milidetik diperkenalkan, jadi kita sudah mencapai titik yang terlihat oleh manusia. Jika skrip itu sering dipanggil, itu akan menyebabkan masalah kinerja pada sistem. Optimalisasi bukan lelucon dan seluruh dunia tidak membalikkan PC Anda. Ada sepuluh ribu CPU yang digunakan.
John

2
@ John. Itu adalah lelucon yang dibuat dengan semangat yang baik. Tidak ada niat jahat yang dimaksudkan. Jika layak bagi Anda untuk mengoptimalkan menyertakan Anda, silakan saja.
Andrew Ensley

66

Saya jadi penasaran dan melihat tautan Adam Backstrom ke Tech Your Universe . Artikel ini menjelaskan salah satu alasan yang mengharuskan harus digunakan alih-alih require_once. Namun, klaim mereka tidak sesuai dengan analisis saya. Saya akan tertarik melihat di mana saya mungkin telah misanalysed solusinya. Saya menggunakan PHP 5.2.0 untuk perbandingan.

Saya mulai dengan membuat 100 file header yang menggunakan require_once untuk memasukkan file header lainnya. Masing-masing file ini terlihat seperti:

<?php
    // /home/fbarnes/phpperf/hdr0.php
    require_once "../phpperf/common_hdr.php";

?>

Saya membuat ini menggunakan Bash hack cepat:

for i in /home/fbarnes/phpperf/hdr{00..99}.php; do
    echo "<?php
    // $i" > $i
    cat helper.php >> $i;
done

Dengan cara ini saya bisa dengan mudah bertukar antara menggunakan require_once dan membutuhkan ketika menyertakan file header. Saya kemudian membuat app.php untuk memuat seratus file. Ini terlihat seperti:

<?php
    // Load all of the php hdrs that were created previously
    for($i=0; $i < 100; $i++)
    {
        require_once "/home/fbarnes/phpperf/hdr$i.php";
    }

    // Read the /proc file system to get some simple stats
    $pid = getmypid();
    $fp = fopen("/proc/$pid/stat", "r");
    $line = fread($fp, 2048);
    $array = split(" ", $line);

    // Write out the statistics; on RedHat 4.5 with kernel 2.6.9
    // 14 is user jiffies; 15 is system jiffies
    $cntr = 0;
    foreach($array as $elem)
    {
        $cntr++;
        echo "stat[$cntr]: $elem\n";
    }
    fclose($fp);
?>

Saya membandingkan header require_once dengan header yang menggunakan file header seperti:

<?php
    // /home/fbarnes/phpperf/h/hdr0.php
    if(!defined('CommonHdr'))
    {
        require "../phpperf/common_hdr.php";
        define('CommonHdr', 1);
    }
?>

Saya tidak menemukan banyak perbedaan ketika menjalankan ini dengan require vs require_once. Sebenarnya, tes awal saya sepertinya menyiratkan bahwa require_once sedikit lebih cepat, tapi saya tidak perlu percaya itu. Saya mengulangi percobaan dengan 10.000 file input. Di sini saya memang melihat perbedaan yang konsisten. Saya menjalankan tes beberapa kali, hasilnya dekat tetapi menggunakan require_once menggunakan rata-rata 30,8 pengguna jiffies dan 72,6 sistem jiffies; menggunakan memerlukan menggunakan rata-rata 39,4 pengguna jiffies dan 72,0 sistem jiffies. Oleh karena itu, tampak bahwa bebannya sedikit lebih rendah menggunakan require_once. Namun, waktu jam dinding sedikit meningkat. 10.000 panggilan need_once menggunakan rata-rata 10,15 detik untuk menyelesaikan dan rata-rata 10.000 panggilan menggunakan 9,84 detik.

Langkah selanjutnya adalah melihat perbedaan-perbedaan ini. Saya menggunakan strace untuk menganalisis panggilan sistem yang sedang dibuat.

Sebelum membuka file dari require_once, panggilan sistem berikut dilakukan:

time(NULL)                              = 1223772434
lstat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/fbarnes", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/fbarnes/phpperf", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/fbarnes/phpperf/h", {st_mode=S_IFDIR|0755, st_size=270336, ...}) = 0
lstat64("/home/fbarnes/phpperf/h/hdr0.php", {st_mode=S_IFREG|0644, st_size=88, ...}) = 0
time(NULL)                              = 1223772434
open("/home/fbarnes/phpperf/h/hdr0.php", O_RDONLY) = 3

Ini kontras dengan membutuhkan:

time(NULL)                              = 1223772905
lstat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/fbarnes", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/fbarnes/phpperf", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/fbarnes/phpperf/h", {st_mode=S_IFDIR|0755, st_size=270336, ...}) = 0
lstat64("/home/fbarnes/phpperf/h/hdr0.php", {st_mode=S_IFREG|0644, st_size=146, ...}) = 0
time(NULL)                              = 1223772905
open("/home/fbarnes/phpperf/h/hdr0.php", O_RDONLY) = 3

Tech Your Universe menyiratkan bahwa require_once harus membuat lebih banyak panggilan lstat64. Namun, keduanya melakukan panggilan lstat64 dengan jumlah yang sama. Mungkin, perbedaannya adalah saya tidak menjalankan APC untuk mengoptimalkan kode di atas. Namun, selanjutnya saya membandingkan output strace untuk seluruh proses:

[fbarnes@myhost phpperf]$ wc -l strace_1000r.out strace_1000ro.out
  190709 strace_1000r.out
  210707 strace_1000ro.out
  401416 total

Secara efektif ada sekitar dua panggilan sistem per file header saat menggunakan require_once. Salah satu perbedaannya adalah require_once memiliki panggilan tambahan ke fungsi time ():

[fbarnes@myhost phpperf]$ grep -c time strace_1000r.out strace_1000ro.out
strace_1000r.out:20009
strace_1000ro.out:30008

Panggilan sistem lainnya adalah getcwd ():

[fbarnes@myhost phpperf]$ grep -c getcwd strace_1000r.out strace_1000ro.out
strace_1000r.out:5
strace_1000ro.out:10004

Ini disebut karena saya memutuskan jalur relatif yang direferensikan dalam file hdrXXX. Jika saya menjadikan ini sebagai referensi absolut, maka satu-satunya perbedaan adalah panggilan waktu tambahan (NULL) yang dibuat dalam kode:

[fbarnes@myhost phpperf]$ wc -l strace_1000r.out strace_1000ro.out
  190705 strace_1000r.out
  200705 strace_1000ro.out
  391410 total
[fbarnes@myhost phpperf]$ grep -c time strace_1000r.out strace_1000ro.out
strace_1000r.out:20008
strace_1000ro.out:30008

Ini tampaknya menyiratkan bahwa Anda dapat mengurangi jumlah panggilan sistem dengan menggunakan jalur absolut daripada jalur relatif. Satu-satunya perbedaan di luar itu adalah panggilan waktu (NULL) yang tampaknya digunakan untuk menginstruksikan kode untuk membandingkan apa yang lebih cepat.

Satu catatan lain adalah bahwa paket optimasi APC memiliki opsi yang disebut "apc.include_once_override" yang mengklaim bahwa itu mengurangi jumlah panggilan sistem yang dilakukan oleh require_once dan panggilan include_once (lihat dokumentasi PHP ).


6
Dan setiap "optimasi" yang harus Anda jalankan 10.000 kali untuk melihat perbedaan yang sangat kecil bahkan tidak layak untuk dikhawatirkan. Gunakan profiler dan mencari tahu di mana sebenarnya bottleneck dalam aplikasi Anda. Saya ragu pertanyaan ini adalah hambatannya.
DGM

1
Artinya semua ini adalah bahwa itu tidak masalah sama sekali. Gunakan apa pun yang lebih baik untuk Anda secara logis.
Buttle Butkus

wat are jiffies
OverCoder

21

Bisakah Anda memberi kami tautan ke praktik pengkodean ini yang mengatakan untuk menghindarinya? Sejauh yang saya ketahui, ini sepenuhnya bukan masalah . Saya belum melihat kode sumber sendiri, tapi saya akan membayangkan bahwa satu-satunya perbedaan antara includedan include_onceadalah yang include_oncemenambahkan nama file ke array dan memeriksa array setiap kali. Akan mudah untuk menjaga array itu diurutkan, jadi mencari di atasnya harus O (log n), dan bahkan aplikasi menengah-hanya akan memiliki beberapa lusin termasuk.


satu adalah, chazzuka.com/blog/?p=163 mereka benar-benar tidak 'tidak mau', tetapi terlalu banyak hal 'mahal' dijumlahkan. dan sebenarnya, semua file yang disertakan / diperlukan ditambahkan ke array internal (ada fungsi untuk mengembalikannya), saya kira _once harus mengulangi array itu dan melakukan strcmp, yang akan bertambah
Uberfuzzy

7

Cara yang lebih baik untuk melakukan sesuatu adalah menggunakan pendekatan berorientasi objek dan menggunakan __autoload () .


3
tetapi contoh pertama di halaman objek autoloading yang Anda
tautkan

Saya tidak membeli ini. Ada beberapa situasi di mana OO tidak sesuai dengan paradigma lain, jadi Anda tidak boleh memaksanya hanya untuk mendapatkan keuntungan kecil apa pun yang mungkin ada dengan __autoload ().
Bobby Jack

1
Anda akan berpikir bahwa pengisian otomatis sebenarnya membutuhkan waktu lebih lama dari * _cece (dengan asumsi bahwa Anda hanya memerlukan apa yang Anda butuhkan).
nickf

Tidak itu tidak, setidaknya tidak pasti, Autoload masih perlu dimasukkan entah bagaimana dan ini adalah pilihan terakhir untuk PHP sebelum kesalahan gagal - jadi pada kenyataannya PHP sebenarnya melakukan pemeriksaan yang mungkin tidak perlu melalui semua tempat yang akan diterapkan untuk menyertakan / membutuhkan dan SETELAH BAHWA itu akan memanggil pengisian otomatis (jika ada yang ditentukan) ... PS: __autoload()tidak disarankan dan mungkin akan usang di masa mendatang, Anda harus menggunakan spl_autoload_register(...)hari-hari ini ... PS2: jangan salah, saya kadang-kadang menggunakan fungsi pengisian otomatis; )
jave.web

6

Itu tidak menggunakan fungsi yang buruk. Ini adalah pemahaman yang salah tentang bagaimana dan kapan menggunakannya, dalam basis kode keseluruhan. Saya hanya akan menambahkan sedikit konteks pada gagasan yang mungkin disalahpahami ini:

Orang seharusnya tidak berpikir bahwa require_once adalah fungsi yang lambat. Anda harus memasukkan kode Anda dengan satu atau lain cara. Kecepatan require_once()vs require()bukan masalahnya. Ini tentang kinerja yang menghambat peringatan yang dapat menyebabkan penggunaannya secara membabi buta. Jika digunakan secara luas tanpa mempertimbangkan konteks, ini dapat menyebabkan pemborosan memori yang besar atau kode yang boros.

Apa yang saya lihat itu benar-benar buruk, adalah ketika kerangka kerja monolitik besar menggunakan require_once()semua cara yang salah, terutama dalam lingkungan berorientasi objek (OO) yang kompleks.

Ambil contoh penggunaan require_once()di bagian atas setiap kelas seperti yang terlihat di banyak perpustakaan:

require_once("includes/usergroups.php");
require_once("includes/permissions.php");
require_once("includes/revisions.php");
class User{
  // User functions
}

Jadi Userkelas dirancang untuk menggunakan ketiga kelas lainnya. Cukup adil!

Tapi sekarang bagaimana jika pengunjung menelusuri situs dan bahkan tidak masuk dan kerangka memuat: require_once("includes/user.php");untuk setiap permintaan tunggal.

Ini termasuk 1 + 3 kelas yang tidak perlu yang tidak akan pernah digunakan selama permintaan khusus itu. Beginilah kerangka kerja yang kembung akhirnya menggunakan 40 MB per permintaan dibandingkan dengan 5 MB atau kurang.


Cara lain yang bisa disalahgunakan, adalah ketika kelas digunakan kembali oleh banyak orang lain! Katakanlah Anda memiliki sekitar 50 kelas yang menggunakan helperfungsi. Untuk memastikan helperstersedia untuk kelas-kelas tersebut ketika mereka dimuat, Anda mendapatkan:

require_once("includes/helpers.php");
class MyClass{
  // Helper::functions(); // etc..
}

Tidak ada yang salah di sini. Namun jika satu permintaan halaman menyertakan 15 kelas yang sama. Anda menjalankan require_once15 kali, atau untuk visual yang bagus:

require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");
require_once("includes/helpers.php");

Penggunaan require_once () secara teknis mempengaruhi kinerja untuk menjalankan fungsi itu 14 kali, selain harus mengurai baris-baris yang tidak perlu. Dengan hanya 10 kelas yang sangat sering digunakan dengan masalah yang sama, itu bisa menjelaskan 100+ baris kode berulang yang agak tidak berguna.

Dengan itu, mungkin layak digunakan require("includes/helpers.php");di bootstrap aplikasi atau kerangka kerja Anda. Tapi karena semuanya relatif, itu semua tergantung apakah bobot versus frekuensi penggunaan helperskelas layak menghemat 15-100 baris require_once(). Tetapi jika probabilitas tidak menggunakan helpersfile pada permintaan yang diberikan tidak ada, maka requireseharusnya harus di kelas utama Anda sebagai gantinya. Memiliki require_oncedi setiap kelas secara terpisah menjadi pemborosan sumber daya.


The require_onceFungsi ini berguna bila diperlukan, tetapi tidak harus dianggap sebagai solusi monolitik untuk menggunakan mana-mana untuk memuat semua kelas.


5

Wiki PEAR2 (bila ada) digunakan untuk membuat daftar alasan yang baik untuk meninggalkan semua arahan yang memerlukan / menyertakan yang mendukung pemuatan otomatis , setidaknya untuk kode pustaka. Ini mengikat Anda ke struktur direktori yang kaku ketika model kemasan alternatif seperti phar berada di cakrawala.

Pembaruan: Karena versi arsip web dari wiki jelek sekali, saya telah menyalin alasan paling meyakinkan di bawah ini:

  • include_path diperlukan untuk menggunakan paket (PEAR). Ini menyulitkan untuk menggabungkan paket PEAR dalam aplikasi lain dengan include_path sendiri, untuk membuat file tunggal yang berisi kelas yang diperlukan, untuk memindahkan paket PEAR ke arsip phar tanpa modifikasi kode sumber yang luas.
  • ketika tingkat atas memerlukan_once dicampur dengan persyaratan_syarat bersyarat, ini dapat menghasilkan kode yang tidak dapat di-cache oleh cache opcode seperti APC, yang akan dibundel dengan PHP 6.
  • require_once relatif mensyaratkan bahwa include_path sudah disetel ke nilai yang benar, sehingga tidak mungkin untuk menggunakan paket tanpa include_path yang tepat

5

The *_once()fungsi -stat setiap direktori induk untuk memastikan file Anda termasuk tidak sama sebagai salah satu yang sudah dimasukkan. Itu bagian dari alasan perlambatan.

Saya sarankan menggunakan alat seperti Pengepungan untuk pembandingan. Anda dapat mencoba semua metodologi yang disarankan dan membandingkan waktu respons.

Lebih lanjut tentang require_once()ada di Tech Your Universe .


Terima kasih atas penunjuk ke artikel. require_once () adalah sabuk pengaman yang baik untuk file yang menyertakan dua kali lipat, dan kami akan terus menggunakannya, tetapi bisa membuatnya bersih itu bagus.
Andy Lester

2

Bahkan jika require_oncedan include_once lebih lambat daripada requiredan include(atau alternatif apa pun yang mungkin ada), kita berbicara tentang tingkat terkecil optimasi mikro di sini. Waktu Anda jauh lebih baik dihabiskan untuk mengoptimalkan perulangan atau kueri basis data yang buruk daripada mengkhawatirkan sesuatu seperti itu require_once.

Sekarang, orang dapat membuat argumen yang mengatakan bahwa require_oncepraktik pengkodean yang buruk dapat dilakukan karena Anda tidak perlu memperhatikan menjaga kebersihan dan keteraturan Anda, tetapi itu tidak ada hubungannya dengan fungsi itu sendiri dan terutama bukan kecepatannya.

Jelas, autoloading lebih baik demi kebersihan kode dan kemudahan pemeliharaan, tetapi saya ingin menjelaskan bahwa ini tidak ada hubungannya dengan kecepatan .


0

Anda menguji, menggunakan menyertakan, alternatif oli dan __autoload (); dan mengujinya dengan sesuatu seperti APC diinstal.

Saya ragu menggunakan konstanta akan mempercepat.


0

Ya, ini sedikit lebih mahal daripada yang dibutuhkan (). Saya pikir intinya adalah jika Anda dapat menjaga kode Anda cukup teratur untuk tidak duplikat termasuk, jangan gunakan fungsi * _once (), karena akan menghemat beberapa siklus.

Tetapi menggunakan fungsi _once () tidak akan mematikan aplikasi Anda. Pada dasarnya, jangan gunakan itu sebagai alasan untuk tidak perlu mengatur termasuk Anda . Dalam beberapa kasus, menggunakannya masih tidak dapat dihindari, dan itu bukan masalah besar.


-2

Saya pikir dalam dokumentasi PEAR, ada rekomendasi untuk mengharuskan, require_once, sertakan dan sertakan_once. Saya memang mengikuti pedoman itu. Aplikasi Anda akan lebih jelas.


Beberapa referensi akan disusun.
Peter Mortensen

-3

Ini tidak ada hubungannya dengan kecepatan. Ini tentang gagal dengan anggun.

Jika require_once () gagal, skrip Anda selesai. Tidak ada yang diproses. Jika Anda menggunakan include_once () skrip Anda yang lain akan mencoba untuk melanjutkan render, sehingga pengguna Anda berpotensi tidak akan mengetahui apa pun yang gagal dalam skrip Anda.


1
Belum tentu. Anda benar-benar dapat menghubungkan penangan kesalahan atau penangan shutdown untuk memberikan pengguna halaman kesalahan yang bagus (meskipun orang jarang melakukannya). Sebagai pengembang, saya lebih suka kesalahan segera.
Edward Z. Yang

1
Atau, seperti kasusnya, tidak gagal dengan anggun - jika beberapa file vital tidak memerlukan () benar, itu ide yang baik hanya untuk menyerah dan berhenti. Tapi itu perlu vs sertakan, sedangkan saya pikir pertanyaannya lebih fokus pada mengharuskan vs require_once.
HoboBen

-4

Pendapat pribadi saya adalah bahwa penggunaan require_once (atau include_once) adalah praktik yang buruk karena require_once memeriksa Anda jika Anda sudah menyertakan file itu dan menekan kesalahan dua file yang dimasukkan yang mengakibatkan kesalahan fatal (seperti duplikat fungsi / kelas / dll.) .

Anda harus tahu jika Anda perlu memasukkan file.

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.