Відкриття / закриття тегів та продуктивність?

Це може бути безглуздим запитанням, але як хтось відносно новий для PHP, мені цікаво, чи є проблеми, пов'язані з продуктивністю, щодо частого відкриття та закриття тегів PHP у коді шаблону HTML, і якщо так, то що може бути найкращою практикою з точки зору роботи з тегами PHP?

Моє питання полягає не в важливості / правильності закриття тегів, а також у тому, який тип коду читабельніший за інший, а в тому, як документ аналізується / виконується та який вплив він може мати на продуктивність.

Для ілюстрації розглянемо наступні дві крайності:

Змішування тегів PHP та HTML:

<?php echo
   '<tr>
       <td>'.$variable1.'</td>
       <td>'.$variable2.'</td>
       <td>'.$variable3.'</td>
       <td>'.$variable4.'</td>
       <td>'.$variable5.'</td>
   </tr>'
?>
// PHP tag opened once

Розділення тегів PHP та HTML:

<tr>
   <td><?php echo $variable1 ?></td>
   <td><?php echo $variable2 ?></td>
   <td><?php echo $variable3 ?></td>
   <td><?php echo $variable4 ?></td>
   <td><?php echo $variable5 ?></td>
</tr>
// PHP tag opened five times

Було б цікаво почути деякі погляди на це, навіть якщо це просто почути, що це не має значення.

Дякую.

3 простих правила, щоб ви це правильно зрозуміли:

• Жодна проблема синтаксису не може вплинути на продуктивність. Маніпулювання даними робить.
• Мова про ефективність лише підкріплена результатами профілювання .
• Передчасна оптимізація - корінь усього зла

Проблеми з продуктивністю досить важко зрозуміти. Новачкам рекомендується не брати це до уваги. Тому що вони завжди вражені дрібницями і не бачать справді важливих речей. Просто через відсутність досвіду.

Те саме для вашого запитання. Уявіть, ви коли-небудь отримаєте якусь різницю. Навіть великий, скажімо, один метод вдвічі швидший. Ох, 2 рази! Я вибрав його та добре оптимізував свій додаток, зараз він працюватиме на 50% швидше!

Неправильно . Не 50%. Ви ніколи не помітите і навіть не виміряєте цього збільшення швидкості. Оскільки ви оптимізували частину, яка займає лише 0,0001% всього сценарію.

Що стосується великих таблиць HTML, то браузеру потрібно багато часу, щоб їх відтворити. Набагато більше, ніж ви взяли для генерації.

Профілювання - ключове слово у світі виступу. Будь-яке питання, пов’язане з продуктивністю, можна сумніватися, не сумніваючись, якщо в ньому немає слова „профілювання”. У той же час профілювання не є ракетною наукою. Я просто вимірюю час роботи різних частин вашого сценарію. Це можна зробити за допомогою якогось профілі, наприклад, xdebug, або навіть вручну, використовуючи microtime(1). І лише виявивши найповільнішу частину, ви можете почати з тестів.

Навчіться профілювати, перш ніж задавати питання продуктивності. І навчіться не задавати запитань щодо продуктивності, якщо для цього немає реальних причин.

Передчасна оптимізація - корінь усього зла - Д.Кнут .

Я переробив тести з 50 000 рядків і також додав метод багатоехо в 1 тегу

for ($j=0;$j<30;$j++) {
    foreach ($results as $key=>$val){
    ?>
       <tr>
           <td><?php echo $results[$key][0]?></td>
           <td><?php echo $results[$key][1]?></td>
           <td><?php echo $results[$key][2]?></td>
           <td><?php echo $results[$key][3]?></td>
           <td><?php echo $results[$key][4]?></td>
           <td><?php echo $results[$key][5]?></td>
           <td><?php echo $results[$key][6]?></td>
           <td><?php echo $results[$key][7]?></td>
           <td><?php echo $results[$key][8]?></td>
           <td><?php echo $results[$key][9]?></td>
           <td><?php echo $results[$key][10]?></td>
           <td><?php echo $results[$key][11]?></td>
           <td><?php echo $results[$key][12]?></td>
           <td><?php echo $results[$key][13]?></td>
           <td><?php echo $results[$key][14]?></td>              
       </tr>
    <?php 
    }
}

тривалість1: 31.15542483 секунд

for ($k=0;$k<30;$k++) {
    foreach ($results as $key1=>$val1){
        echo
           '<tr>
               <td>'.$results[$key1][0].'</td>
               <td>'.$results[$key1][1].'</td>
               <td>'.$results[$key1][2].'</td>
               <td>'.$results[$key1][3].'</td>
               <td>'.$results[$key1][4].'</td>
               <td>'.$results[$key1][5].'</td>
               <td>'.$results[$key1][6].'</td>
               <td>'.$results[$key1][7].'</td>
               <td>'.$results[$key1][8].'</td>
               <td>'.$results[$key1][9].'</td>
               <td>'.$results[$key1][10].'</td>
               <td>'.$results[$key1][11].'</td>
               <td>'.$results[$key1][12].'</td>
               <td>'.$results[$key1][13].'</td>
               <td>'.$results[$key1][14].'</td>              
           </tr>';
    }
}

тривалість2: 30,23169804 секунди

for ($l=0;$l<30;$l++) {
    foreach ($results as $key2=>$val2){     
           echo'<tr>';
               echo'<td>'.$results[$key2][0].'</td>';
               echo'<td>'.$results[$key2][1].'</td>';
               echo'<td>'.$results[$key2][2].'</td>';
               echo'<td>'.$results[$key2][3].'</td>';
               echo'<td>'.$results[$key2][4].'</td>';
               echo'<td>'.$results[$key2][5].'</td>';
               echo'<td>'.$results[$key2][6].'</td>';
               echo'<td>'.$results[$key2][7].'</td>';
               echo'<td>'.$results[$key2][8].'</td>';
               echo'<td>'.$results[$key2][9].'</td>';
               echo'<td>'.$results[$key2][10].'</td>';
               echo'<td>'.$results[$key2][11].'</td>';
               echo'<td>'.$results[$key2][12].'</td>';
               echo'<td>'.$results[$key2][13].'</td>';
               echo'<td>'.$results[$key2][14].'</td>';              
           echo'</tr>';
    }
}

тривалість3: 27,54640007 секунд

Не велика різниця між початковими 2 методами, але схоже, це набагато швидше, з меншим об'єднанням @poke

Оскільки я сумніваюся, що мені знадобиться стільки даних за один прийом, я думаю, я й надалі використовуватиму багато тегів, відступ коду виглядає акуратніше, а макет "переглянути джерело" точнішим

Ви можете легко ігнорувати різницю в продуктивності між цими двома. З сучасними обчислювальними ресурсами різниця насправді не має значення. Про такі матеріали для друку на екрані справді не варто турбуватися. Існує маса інших речей, про які ви повинні розглянути раніше. Окрім цього, завжди ведуться суперечки між найкращою продуктивністю та ремонтопридатністю вашого коду. Не завжди можна намагатися досягти найкращих показників. Натомість вам завжди слід враховувати проблеми ефективності, а також кількість часу, який потрібно витратити на їх покращення.

Код, який легко перекласти на псевдокод, краще. Про це свідчать наведені вище приклади. Що вимагає більше часу, щоб сказати?

"Start php, do this 30 times:, then stop php.  Print this.  Start php, print this, stop php. Print this.  Start php, print this, stop php.Print this.  Start php, print this, stop php. Print this.  Start php, print this, stop php.Print this.  Start php, print this, stop php. Print this.  Start php, print this, stop php.Print this.  Start php, print this, stop php..."

"Start php, do this 30 times: print this, then add this to that, then add this to that, then add this to that, then add this to that, then add this to that, then add this to that..."

"Start php, do this 30 times: print this, print this, print this, print this, print this, print this, print this..."

Особисто я б зробив:

"Start php, define this, do this 30 times: add this to that.  Print." 

Технічне пояснення того, як працює перекладач, і чому один шлях швидший за інший, не має значення для новачка. Найкраще просто знати емпіричні правила:

1. Простіше - краще.
2. Якщо він не вміщується на одній сторінці, це робить занадто багато (розбийте його).
3. Якщо ви не можете вручну написати псевдокод на індексній картці, це занадто складно.

Використовуйте більше тегів, якщо загальний результат простіший. Період.

Справжньою проблемою цього є використання пам'яті. Конкатенація рядків та масове відлуння можуть збільшити використання пам'яті експоненціально.

Якщо ви спамуєте php-тег, ваш код стає нечитабельним.

Найкраще рішення - використовувати механізм шаблонів і взагалі уникати змішування коду та презентації.