jQuery организация и производительность кода

Проведя некоторое исследование по этому вопросу, я много экспериментировал с шаблонами для организации своего кода jQuery (например, Ребекка Мерфи сделала презентацию по этому вопросу на конференции jQuery).

Вчера я проверил (показательный) шаблон модуля. Результат выглядит немного напоминающим синтаксис YUI , я думаю:

//global namespace MyNameSpace
if(typeof MNS=="undefined"||!MNS){var MNS={};}

//obfuscate module, just serving as a very simple example
MNS.obfuscate = function(){
    //function to create an email address from obfuscated '@'
    var email = function(){
        $('span.email').each(function(){
            var emailAddress = $(this).html().replace(' [ @ ] ','@');
            $(this).html('' + emailAddress + '');

        });
    };    
    return {
        email: email
    };    
}();

//using the module when the dom's ready
jQuery(document).ready(function($){
    MNS.obfuscate.email();
});

В итоге у меня было несколько модулей. Некоторые естественным образом включали «закрытые члены», которые в данном случае означают переменные и / или функции, которые имели значение только для других функций в этом модуле и, таким образом, не заканчивались в операторе return.

Я думал, что связал части мой код (все, что связано с поиском, например), объединенный в модуле, имеет смысл, дает всю структуру.

Но после написания этого, я прочитал статью Джона (Resig ) ), где он также пишет о производительности шаблона модуля:

«Создание функции с кучей свойств прототипа выполняется очень и очень быстро. Он полностью выдувает образец модуля и тому подобное из воды. Таким образом, если у вас есть часто используемая функция (возвращающая объект), с которой вы хотите, чтобы люди взаимодействовали, то вам выгодно иметь свойства объекта в цепочке прототипов и создавать их экземпляры. Вот это, в коде:

// Very fast
function User(){}
    User.prototype = { /* Lots of properties ... */ };

// Very slow
function User(){
    return { /* Lots of properties */ };
}

(Джон упоминает, что он не против шаблона модуля «per se», хотя - просто, чтобы вы знали:)

Тогда я больше не был уверен, собираюсь ли я идти вправо направление с моим кодом. Дело в том, что мне действительно не нужны какие-либо частные члены, и я также не думаю, что мне нужно наследование на данный момент. В ваших интересах иметь свойства объекта в цепочке прототипов и создавать их экземпляры. Вот это, в коде:

// Very fast
function User(){}
    User.prototype = { /* Lots of properties ... */ };

// Very slow
function User(){
    return { /* Lots of properties */ };
}

(Джон упоминает, что он не против шаблона модуля «per se», хотя - просто, чтобы вы знали:)

Тогда я больше не был уверен, собираюсь ли я идти вправо направление с моим кодом. Дело в том, что мне действительно не нужны какие-либо частные члены, и я также не думаю, что мне нужно наследование на данный момент. В ваших интересах иметь свойства объекта в цепочке прототипов и создавать их экземпляры. Вот это, в коде:

// Very fast
function User(){}
    User.prototype = { /* Lots of properties ... */ };

// Very slow
function User(){
    return { /* Lots of properties */ };
}

(Джон упоминает, что он не против шаблона модуля «per se», хотя - просто, чтобы вы знали:)

Тогда я больше не был уверен, собираюсь ли я идти вправо направление с моим кодом. Дело в том, что мне действительно не нужны какие-либо частные члены, и я также не думаю, что мне нужно наследование на данный момент. Все, что я хочу сейчас, это читаемый / поддерживаемый шаблон. Я предполагаю, что это сводится к личным предпочтениям в определенной степени, но я не хочу в конечном итоге иметь читаемый код, который имеет (довольно серьезные) проблемы с производительностью.

Я не эксперт по JavaScript и, следовательно, даже менее эксперт, когда речь идет о тестировании производительности. Итак, во-первых, я действительно не знаю, в какой степени те вещи, о которых говорил Джон («часто доступная функция (возвращающая объект), с которыми вы хотите, чтобы люди взаимодействовали», множество свойств и т. Д.), Применимы к моему коду. Документы, с которыми взаимодействует мой код, не очень большие, с сотнями или тысячами элементов. Так что, возможно, это совсем не проблема.

Но одна вещь, которая пришла мне в голову, состоит в том, что вместо того, чтобы просто иметь

$('span.email').each(function(){
    var emailAddress = $(this).html().replace(' [ @ ] ','@');
    $(this).html('' + emailAddress + '');
});

(внутри функции domready), я создаю две «дополнительные» функции, obfuscate и email, из-за использования шаблона модуля. Создание дополнительных функций стоит времени. Вопрос в том, будет ли это измеримо в моем случае?

Я не уверен, создано ли замыкание в моем примере выше (в интересном посте на форуме jQuery я прочитал следующее: «Существует философская дискуссия о создает ли внутренняя функция замыкание, если она ничего не ссылается на объект переменной внешней функции ... "), но у меня были замыкания в моем реальном коде. И хотя я не думаю, что у меня там были какие-то циклические ссылки, я не знаю, насколько это может привести к высокому (er) потреблению памяти / проблемам со сборкой мусора.

Мне бы очень хотелось услышать ваш вклад в это, и, возможно, увидеть некоторые примеры вашего кода. Кроме того, какие инструменты вы предпочитаете получать информацию о времени выполнения, использование памяти и ЦП?