Hiện có rất nhiều nếu báo cáo làm suy giảm tốc độ rendering của php?

Question

Tôi đã tự hỏi nếu phức tạp nếu/cấu trúc khác trong mã PHP của tôi có thể là một quyết định thiết kế xấu. Có rất nhiều câu lệnh if làm cho PHP chạy chậm, tải trang web chậm hơn không?

Đây là mã: (Tôi không biết cách xử lý wordpress is_page, vv)

<?php 

if (is_page()) { 
// 
    if (is_page(122)) { 
    //subscribe page 
    echo "subscribe page"; 

    } 

    elseif (is_page(1263)) { 
    //photography course 
    echo "photography course page"; 

    } 

    elseif (is_page(array(210,184,128))) { 
    //210 copyright policy, 184 privacy policy, 128 contact 
    echo "this is either copyright policy, privacy or contact page!"; 
    //nothing happens here, we don't need social buttons on these pages. 
    } 

    elseif (is_page(array(379,71,7,45,124,8,105,175,9,125,110))) { 
    //379 photo galleries, 71 car photos, 7 conceptual, 45 event photos, 124 fashion, 8 landscape, 105 misc, 175 journalism, 9 portrait, 125 street photography, 110 travel 
    echo "gallery pages and albums"; 

    } 

    else { 
    //any other page 
    echo "any other page"; 

    } 
// 
} 

elseif (is_single()) { 
// 
    if (in_category(array(147,196,35))) { 
    //147 car photography, 196 car wallpapers, 35 photo stories 
    echo "photo posts"; 

    } 
    else { 
    //any other post 
    echo "any other post"; 

    } 
// 
} 

elseif (is_archive()) { 
// 
    //any category 
    echo "this is archive template" 

} 
// 
?> 

Answer 1

Không. Trong thực tế, nó sẽ thực sự tăng tốc nó trong hầu hết các trường hợp (vì nó được phép bỏ qua các khối mã).

Chỉ một số lượng lớn các câu lệnh if sẽ làm chậm nó xuống nếu điều kiện bạn đang kiểm tra yêu cầu xử lý. Một ví dụ sẽ giống như sau:

while (true) 
{ 
    if (count($some_array) == 0) { break; } 
    /* some other code */ 
} 

Bao giờ lặp lại qua vòng kiểm tra nếu count($some_array) == 0. Điều đó có nghĩa là mỗi lần vượt qua, PHP phải truy cập và số lượng các mục trong số $some_array theo cách thủ công bởi vì nó có thể đã thay đổi. Điều này cũng áp dụng cho điều kiện dừng trong vòng lặp for. Điều này là do một vòng lặp for luôn có thể được viết lại như một vòng lặp while:

for ([INITIALIZER_ACTION]; [CONDITION]; [POST_ITERATION_ACTION]) { [CODE]; } 

cũng giống như ...

[INITIALIZER_ACTION]; 
while ([CONDITION]) { [CODE]; [POST_ITERATION_ACTION]; } 

Nếu bạn đang cân nhắc việc sáp nhập một bó nếu báo cáo thành một: không, bạn sẽ không nhận được bất kỳ lợi ích nào. PHP không mạch ngắn có nghĩa là nếu nó đạt đến một điểm mà nó biết kết quả sẽ là gì, nó sẽ bỏ qua phần còn lại.

Ví dụ: xem xét $a = 5; if ($a > 0 || $b > 100 || $c > 200) {}.
Khi PHP thấy rằng điều kiện $a > 0 được thỏa mãn, toàn bộ câu lệnh được giải quyết thành true (vì việc sử dụng giá trị OR) và không bận tâm kiểm tra $b > 100 hoặc $c > 200.

Vì vậy, để trả lời câu hỏi của bạn: trừ khi bạn có một số không tin kính của điều kiện mà mỗi đòi hỏi tính toán phức tạp hoặc có tác dụng phụ, bạn thường có thể xem xét số lượng của họ được không quan trọng.
Tuy nhiên, như những người khác đã lưu ý, có quá nhiều câu lệnh nếu có thể làm giảm khả năng đọc mã. Trong nhiều trường hợp, nếu bạn có thể loại bỏ một điều kiện mà không ảnh hưởng đến hành vi của mã, thì bạn không cần nó để bắt đầu.

Answer 2

Rất phức tạp if/else cấu trúc cho thấy một thiết kế xấu trong hầu hết các trường hợp. Bạn có thể tập trung tốt hơn vào việc cải thiện thiết kế xấu hơn tối ưu hóa, premature optimization is the root of all evil!.

Nếu bạn đưa ra ví dụ về loại mã bạn đang nói đến, có thể sẽ cung cấp câu trả lời chi tiết hơn.

Answer 3

Nếu mệnh đề là một số hoạt động rẻ nhất, có hiệu suất cao.

Tuy nhiên, những gì bạn đặt trong mệnh đề nếu có thể rất chậm.

Ví dụ: if (true) { ... } sẽ cực kỳ nhanh, nhưng if (calculatePi()) { ... } sẽ mất vĩnh viễn.Bản thân số if nhanh đến mức bạn sẽ không bao giờ phải lo lắng về điều đó, và ngoài ra, mọi thứ khác bạn thực hiện liên quan đến số lượng if s, ví dụ như khi bạn thực hiện các câu lệnh for hoặc while vòng hoặc switch. Tất cả những bản chất đó chứa if (một hoặc nhiều) bên trong chúng.

Đối với thiết kế, rất nhiều if s có thể gây nhầm lẫn cho các nhà phát triển khác, tùy thuộc vào nội dung bạn đang viết và cách viết. Đôi khi bạn nên sử dụng chuyển đổi/báo cáo trường hợp hoặc một số quy trình làm việc khác, nhưng để cho bạn biết sự thật, một loạt các if s có thể sẽ hoạt động nhanh hơn bất kỳ loại cấu trúc nào bạn có thể đưa ra. Nhưng chỉ có điều đó với trái tim nếu mối quan tâm của bạn chỉ là là hiệu suất. Phần mềm thiết kế là không phải, tôi lặp lại, không chủ yếu về hiệu suất. Thiết kế phần mềm tốt là về những thứ khác như bảo trì, tức là dễ đọc và nâng cấp thành công mã của bạn.

Tóm lại, nếu bạn đang tối ưu hóa hiệu suất, đừng bận tâm cố gắng giảm số lượng if s. Thay vào đó tập trung vào những gì mà if đang hỏi về, hoặc điều gì sẽ xảy ra tùy thuộc vào việc chúng trả về đúng hay sai.

Hy vọng điều đó sẽ hữu ích.

Answer 4

Câu hỏi đặt ra không phải là về việc có quá nhiêu nếu báo cáo khác nhưng 1) theo thứ tự của họ và 2) hiệu quả như thế nào điều kiện của bạn là

1) Nếu tình trạng khác nên được theo thứ tự xác suất của các điều kiện tự giảm dần. Trong bảng cơ sở dữ liệu wp_posts cụ thể của tôi, 80% hồ sơ có post_status của "bản nháp", "đang chờ xử lý", "thùng rác", v.v. nhưng không "xuất bản". Khoảng 40% hồ sơ có "bài" là post_type. Vì vậy, nó sẽ làm cho không có ý nghĩa để có

if ($post_type=="post"&&$post_status=="publish") { 
    doA(); 
} elseif ($post_type!="post"&&post_status=="publish") { 
    doB(): 
} elseif ($post_type=="post"&&post_status!="publish") { 
    doC(); 
} else { 
    doD(); 
} 

nhưng nó nên đi theo thứ tự ngược

Về 2), lược đồ cơ sở dữ liệu của WordPress khuyên in_category() sẽ chậm. Nếu đó là một số truy vấn mà bạn viết cho mình và tất nhiên, điều đó phụ thuộc vào mức độ hiệu quả của truy vấn của bạn là

Answer 5

Tôi vừa xem một phần rất thú vị của article từ WPShout sử dụng sự tương tự của con người để mời chúng tôi viết mã thông minh hơn và tại sao các câu lệnh if { .. } lồng nhau sâu sắc có thể làm suy giảm không chỉ hiệu suất mà còn có thể bảo trì mã. Nếu logic là hiệu năng nhận thức, không cần kiểm tra lặp lại không cần thiết, thì rất có thể bạn sẽ kết thúc với một mã được đáp ứng khá tốt, có khả năng đáp ứng tốt hơn.

mã ví dụ (chiết xuất dưới dạng bài viết)

"Hãy làm cho bê tông này bằng cách xem xét hai ví dụ mã đơn giản: đầu tiên trong bong bóng theo phong cách, sau đó trong cửa ngõ kiểu".

Xấu: Bubble-Style

$is_first_thing_working = true; 
$is_second_thing_working = true; 
$is_third_thing_working = true; 
$is_fourth_thing_working = true; 

if($is_first_thing_working === true) { 
    if($is_second_thing_working === true) { 
     if($is_third_thing_working === true) { 
      if($is_fourth_thing_working === true) { 
       return 'Working properly!'; 
      } 
      else { 
       return 'Fourth thing broken.'; 
      } 
     } 
     else { 
      return 'Third thing broken.'; 
     } 
    } 
    else { 
     return 'Second thing broken.'; 
    } 
} 
else { 
    return 'First thing broken.'; 
} 

Tốt: Gateway-Style

$is_first_thing_working = true; 
$is_second_thing_working = true; 
$is_third_thing_working = true; 
$is_fourth_thing_working = true; 

if($is_first_thing_working !== true) { 
    return 'First thing broken.'; 
} 

if($is_second_thing_working !== true) { 
    return 'Second thing broken.'; 
} 

if($is_third_thing_working !== true) { 
    return 'Third thing broken.'; 
} 

if($is_fourth_thing_working !== true) { 
    return 'Fourth thing broken.'; 
} 

return 'Working properly!'; 

GHI CHÚ VỀ VÍ DỤ

Sự khác biệt giữa hai các đoạn mã ở trên sẽ phân tách thành điểm phân biệt chính:

Phương thức bong bóng hỏi xem điều kiện quan trọng có đúng hay không và chỉ chạy mã nếu chúng đúng.

Phương thức cổng yêu cầu nếu điều kiện quan trọng là sai và ngay lập tức đưa ra hướng dẫn thoát cho từng điều kiện nếu sai.

Phương pháp bong bóng tác động đến tổ, bởi vì bạn phải kiểm tra “true, true, true, true” trước khi bạn nhận được mã bạn muốn chạy. Mỗi "true" kiểm tra là một mức độ làm tổ - một điều kiện mã của bạn phải sống bên trong.

Phương thức cổng không được lồng nhau: như bạn thấy, mã không bao giờ nhiều hơn một lớp logic sâu. Điều này là do một khi một cổng đã cho được thông qua, chúng ta có thể quên nó hoàn toàn. Nói cách khác, vì chúng tôi không thoát sau khi séc $is_first_thing_working của chúng tôi, chúng tôi tự động biết rằng $is_first_thing_working là đúng cho phần còn lại của mã.

"Nó giống như cuộc sống thực: nếu bạn đang ngồi bên cạnh tôi trong lớp học lịch sử, tôi biết bạn là một con người, một sinh viên tại trường trung học của tôi, vv-hoặc nếu không bạn sẽ đã chưa bao giờ ở trong lớp của tôi ngay từ đầu. Không cần kiểm tra. "

Answer 6

Nói cách khác .. CÓ.
Tôi nói điều này xem xét một kịch bản trường hợp xấu nhất, trong trường hợp này là một đối tượng mô hình rất lớn với nhiều điều kiện. Ở đây, mã phải trải qua tất cả các kiểm tra có điều kiện mà cuối cùng làm chậm mã.
Báo cáo có điều kiện gây khó khăn cho việc song song và vector hóa, và một chuỗi dài IF-THEN cũng có thể gây ra lỗi bộ nhớ cache lệnh và các hiệu ứng khác. Nhưng nếu đó là những gì làm cho mã rõ ràng nhất, sau đó sử dụng nó.