Питання продуктивності
У попередньому розділі нами вже говорилося, що простий збирання коренів менше впливає на продуктивність. Хоча запис коренів у буфер порівняно з повною відсутністю такий у PHP 5.2 працює повільніше, інші зміни в роботі PHP 5.3 зробили цю втрату продуктивності непомітною.
Є дві основні області, що впливають на продуктивність: зменшення розміру пам'яті, що використовується, і уповільнення роботи при складанні сміття. Розглянемо їх.
Зменшення розміру пам'яті, що використовується
Насамперед, основною причиною реалізації механізму складання сміття є зменшення розміру пам'яті, що використовується за допомогою чищення циклічних посилань, яка відбувається при досягненні відповідних умов. У реалізації PHP це відбувається щойно заповниться кореневий буфер або за виклику функції gc_collect_cycles() . На графіці нижче наведено використання пам'яті скрипта, запущеного в PHP 5.2 та PHP 5.3, без урахування пам'яті, що використовується самим PHP під час запуску.
Приклад #1 Приклад використання пам'яті
У цьому дуже академічному прикладі ми створюємо об'єкт, властивість якого задається посиланням на сам об'єкт. Коли в скрипті в наступній ітерації циклу перевизначається змінна $a, відбувається типова витік пам'яті. В даному випадку зникають два контейнери zval (контейнер об'єкта та контейнер властивості об'єкта), але визначається лише один корінь - віддалена змінна. Як тільки пройдуть 10 000 ітерацій (максимально в кореневому буфері буде 10 000 коренів), то запуститься механізм складання сміття і пам'ять, що займається цим корінням, буде звільнена. Цей процес добре видно на графіку використання пам'яті для PHP 5.3: після кожних 10 000 ітерацій графік просідає. Сам собою механізм у цьому прикладі робить негаразд багато роботи, оскількиструктура витоків дуже проста. З графіка видно, що максимальне використання пам'яті PHP 5.3 склало близько 9 Мб, тоді як у PHP 5.2 воно продовжує зростати.
Уповільнення роботи
Другою областю, де збирання сміття впливає на продуктивність, є втрата часу, коли збирач сміття звільняє пам'ять. Щоб зрозуміти ступінь цього впливу, ми трохи змінимо попередній скрипт, додавши більше ітерацій і проміжних змінних. Змінений скрипт:
Приклад #2 Вплив на продуктивність
echo memory_get_peak_usage (), "\n"; ?>
Ми запустимо скрипт двічі: з увімкненою опцією zend.enable_gc і без неї.
Приклад #3 Запуск скрипту
На тестовій машині перша команда виконується приблизно 10.7 секунд, а друга приблизно 11.4 секунди. Це приблизно на 7% повільніше. Однак максимальне використання пам'яті скриптом зменшилося на 98% з 931 Мб до 10 Мб. Цей тест не дуже науковий, але він дійсно демонструє перевагу використання пам'яті, що забезпечується збирачем сміття. Також добре те, що уповільнення для цього скрипта завжди приблизно 7%, тоді як економія пам'яті збільшується все більше і більше при знаходженні нового сміття.
Внутрішня статистика збирача сміття
Можна отримати трохи більше інформації про те, як механізм збирання сміття виконується в PHP. Але для цього вам необхідно перезбирати PHP для включення тесту продуктивності та коду для додаткового збору даних. Необхідно встановити змінну оточення CFLAGS значення -DGC_BENCH=1 до виконання команди ./configure з вашими параметрами. Наступні команди повинні спрацювати:
Приклад #4 Складання PHP для включення тесту продуктивності GC
При запуску вищенаведеного прикладуоновленим PHP, можна побачити наступну інформацію після завершення роботи скрипту:
Приклад #5 Статистика GC
Найбільш корисна статистика відображена у першому блоці. Можна побачити, що механізм складання сміття було запущено 110 разів, і було звільнено понад 2 мільйони записів у пам'яті. Якщо складання сміття було запущено хоча б раз, то максимальна кількість коренів у буфері завжди дорівнюватиме 10 000.
Висновок
В цілому, збирач сміття в PHP викликає відчутні уповільнення тільки під час безпосередньої роботи механізму складання циклічних посилань, тоді як у звичайних (невеликих) скриптах не повинно бути падіння продуктивності.
Однак у тих випадках, коли механізм складання повинен спрацьовувати і в звичайних скриптах, зниження пам'яті, що використовується, дозволяє одночасно працювати на сервері більшій їх кількості.
Переваги найбільш очевидні для скриптів, що довго працюють, таких як великі набори тестів або демони. Новий механізм також повинен знизити витоку пам'яті для програм PHP-GTK, які зазвичай виконуються довше, ніж веб-скрипти.