Замена JavaScript обратным вызовом - вопрос о производительности
В JavaScript можно определить обработчика обратного вызова в строковых операциях замены regex:
str.replace(/str[123]|etc/, replaceCallback);
Предположите, что у Вас есть объект поиска строк и замен.
var lookup = {"str1": "repl1", "str2": "repl2", "str3": "repl3", "etc": "etc" };
и эта функция обратного вызова:
var replaceCallback = function(match) {
if (lookup[match])
return lookup[match];
else
return match;
}
Как Вы оценили бы выполнение вышеупомянутого обратного вызова? Там твердые пути состоят в том, чтобы улучшить его? Был бы
if (match in lookup) //....
или даже
return lookup[match] || match;
приведите к возможностям для компилятора JS для оптимизации, или действительно ли все это - то же самое?
2 ответа
+1 Энни по поводу тестов производительности.
Но я бы остановился на
return lookup[match] || match;
Это не только однократное получение свойства (а не - запрет оптимизации - два, как в ваших предыдущих примерах), но и короче и (это не всегда верно для более короткого кода) яснее для любого неопытного кодера JavaScript. Это будет немного сбивать с толку новичков, но первое, чему вы хотите научить новичков, - это то, как специальные (и превосходные) || и && работают в JavaScript, поэтому. ..
В некоторых реализациях он также работает с парочкой (очень) крайних случаев.(Пример: 'toString' в {} должно быть истинным [все объекты наследуют toString от прототипа объекта ], но это false в Microsoft JScript.)
Относительно оптимизации: исключая очевидное (не превращайте условие цикла в функцию, которая должна подсчитывать вещи, если она может быть инвариантом, избегайте ненужного дублирования поиска), даже в отсутствие общего обсуждения того, стоит ли беспокоиться об этом, прежде чем вы обнаружите проблему (иногда называемую «преждевременной оптимизацией»), это особенно верно в отношении JavaScript для общей сети. Различные микрооптимизации дают разные результаты в разных реализациях, иногда противоречивые («A» лучше в Internet Explorer, но намного хуже в FireFox, и наоборот). В основном это вопрос ожидания, пока вы не увидите конкретную проблему, а затем приступайте к ее решению.
Я предпочитаю простоту и ясность, если у меня нет веских оснований полагать, что что-то более неуклюжее даст мне измеримое, реальное улучшение.
Вы можете использовать инструмент тестирования, например JSLitmus , для тестирования различных подходов. Обязательно протестируйте разные браузеры.