Вложение дел «переключения» в javascript: какое преимущество в скорости?

Question

вопрос новичка здесь: у меня есть «переключатель», содержащий множество строк.Есть ли преимущество в скорости при разбиении по алфавиту, например, так?

switch(myString.substring(0,1)){
case "a" : switch(myString){
           case "a string beginning with a"       : runCode(); break;
           case "another string beginning with a" : runCode(); break;
           } break;
case "b" : switch(myString){
           case "by golly another string"         : runCode(); break;
           case "blimey - hundreds of strings"    : runCode(); break;
           //... etc

Или язык сценариев читает все строки в любом случае, только чтобы найти закрытые скобки?

Answer 1

Да и нет.Вы бы увидели минимальное увеличение скорости, но не стоит потери читабельности кода от такой структуры.Оператор switch похож на гигантский блок операторов if-else.Он должен переходить от одного случая к другому, пока не найдет то, что ищет, точно так же как с эквивалентной ему структурой if-elseif-else.Таким образом, все, что вы делаете, это помогаете ему пропустить несколько условий.Вложенные операторы switch, особенно написанные здесь, для большинства разработчиков менее читабельны, чем иерархия if-elseif-else.

Answer 2

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

var obj = {
    "aa": runCode,
    "ab": something,
    "ba": foo,
    "bb": bar
};

Тогда вы можете выполнить только с этим, вместо switch es внутри switch es. Он будет искать правильную функцию внутри, что, я думаю, быстрее, чем делать такие вещи самостоятельно:

obj[myString]();

Answer 3

Полагаю, правильный ответ можно измерить эмпирически, и он может варьироваться от одного механизма исполнения JavaScript к другому.

По сути, нам нужно посмотреть, в каком наилучшем случае может быть скомпилирована компиляция сценария.с точки зрения псевдокода.

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

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

ЕСЛИ движок выполнения делает это, чем вложенность оператора switchНа самом деле, я удваиваю затрачиваемое время и, следовательно, замедляю скорость выполнения.

Так что, как правило, для современных движков JavaScript (используемых в браузерах) доверяйте системе делать правильные вещи, не создавая нечитаемый коддля старых и непонятных движков JavaScript (те, которые используются на стороне сервера, которые не являются Node.JS) проверьте, что вы делаете.

Answer 4

Я не проводил тесты на версиях JS, но я знаю, что в PHP есть небольшой недостаток в использовании переключателя по сравнению с if / else, но разница незначительна, и в определенных условиях вы получаете в удобстве чтения / поддержки то, что теряетев скорости (imho).

Тем не менее, я не верю, что вы выиграете здесь скорость, если у вас больше шансов получить результаты a, b, c, чем результаты x, y, z.При оценке операторов case анализатор будет оценивать каждый случай до тех пор, пока не найдет совпадение, а затем опустится в этот код.

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

И операторы переключателя гнезд обычно избегают, потому что они не очень красивы и их трудно читать, что может привести к ошибкам иили расстроенные коллеги.:)