Рекомендації по швидкодії в ie jscript, частина третя проблемні місця js

Рекомендації по швидкодії в IE + JScript, частина третя: проблемні місця JS

Знову привіт, я, Пітер Гуревич (Peter Gurevich), менеджер по оптимізації в IE. Ми отримали безліч відгуків до наших першим нотаток по швидкодії в IE + JScript (Частина 1. Частина 2 (переклад)), і мені не терпиться дізнатися, що ви думаєте про третю частину.

Цього разу ми розглянемо специфічні проблеми, пов'язані з замиканнями і ООП. Уникайте замикань по максимуму, коли це можливо.

Найчастіше замикання використовуються як обробники подій

Це робиться для того, щоб инкапсулировать область видимості виконуваної функції в нову функцію, яка виповниться при виклику відповідного обробника події. Проблема цього підходу - циклічні посилання між змінними і замиканням майже не помітні. Додаткове навантаження на пам'ять в створенні таких об'єктів викликає додаткові витрати на складання сміття, можливо, додаткову роботу для IE або інших браузерів. В якості гарного прикладу можна розглянути API для отримання даних з віддаленого вузла.

Більш того, кожен раз, коли буде викликана функція startDownload. в пам'яті буде виділятися місце під новий об'єкт і його стан.

Не використовуйте методи доступу до властивостей

Часто застосовується техніка в ООП має на увазі використання методів для доступу до властивостей. Наприклад, у вигляді [get / set] _PropertyName (або інші, в завімості від стилю кодування). Спочатку це локальна змінна класу з двома методами для читання і запису змінної. Ці методи часто використовую для контролю видимості членів класу - але в JScript мабуть все. До того ж більшість об'єктно-орієнтованих мов оптимізують ці властивості до прямого доступу до змінної під час компіляції, а це неможливо в JScript як в интерпретируемом мовою.

Наприклад, зразок об'єкта Car. використовує засоби доступу:

Цей приклад прекрасний з точки зору ООП, але жахливий для JScript. Манівці для доступу до локальних членам класу дуже погано впливають на продуктивність програми. Поки нам не потрібна перевірка вхідних значень, ні в якому разі не варто додавати зайвий код: він повинен бути максимально чітким.

Якщо спробувати переписати приклад вище, то вийде хороша вправа на видалення всього, що тільки можна.

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

Для повного прикладу ми також можемо додати прототипи. Врахуйте, що робота з прототипом дійсно не ефективна, так як спочатку пошук члена класу проводитися в екзепляри об'єкта, а потім вже в прототипі. Все це точно зробить наш приклад повільніше. Якщо ви створюєте тисячі примірників об'єкта, тоді прототипи стають, дійсно, ефективними. Це досягається за рахунок зниження розміру кожного об'єкта, так як додаткові властивості не додаються в кожен створюваний екземпляр. Більш того, ініціалізація об'єкта також може бути швидше, так як не потребує кожен раз установки всіх функцій. Для завершення нижче приводитися повний приклад. В якості домашнього завдання спробуйте знайти місця в яких машина на прототипі виграє у повільній машини.

На цьому все з третьою частиною, Дякую.

Peter Gurevich, Program Manager

Justin Rogers, Software Development Engineer