одной и той же задачи и потом использовать более быстрый метод?)
если допустить, что jsperf используется корректно, и выполняется одна и та же задача разными методами, доступными в браузере, а не разные задачи разными методами)
по итогу, когда ты уже знаешь при написании кода, что где-то можно использовать более быстрый метод для этой задачи - ты просто его используешь? это вроде недорого?
к примеру я теперь знаю, что если у меня массив из много айдишек и я хочу проверять наличие айдишки в массиве, то я лучше заюзаю Set вместо arr.includes - для меня это не сильно дорого, и будет одним узким местом меньше на тот момент, когда я захочу оптимизировать профайлером
с промисами убедил, даже захотелось некоторый код на промисы переписать) особенно деструктуризация массива понравилась
поэтому и любопытствую :)
я мог бы подумать сам про ответ на этот вопрос и было бы что-то вроде:
- отвлекаешься на менее значащую ерунду, в тот момент когда надо думать о чём-то более важном
- нужно уже что-то быстро накидать и чем быстрее, тем лучше, потому что обычно надо вчера
Одно дело знать асимптотику стандартных методов, типа Array::indexOf, Array::includes, Set::has, а другое пытаться выяснить что же быстрее Array::forEach или for of используя непонятный пример на jsperf. При этом картинка на вашем коде может быть совершенно другая, потому что на jsperfe был супер урезанный пример, который JIT просто заинлайнил или другим образом оптимизировал, а на вашем коде этого сделать не смог, потому что - 1000 причин почему. У меня была проблема с тем что Object.keys работал сравнительно быстро до определенного момента. Как только появлялся часто менющийся обьект с большим числом ключей, внезапно Object.keys иногда начал выполняться за 100мс. Это было найдено в профайлере и обьект был заменен на Map который в самом худшем раскладе работал в 100раз быстее а в обычном так же быстро как Object.keys.
Обсуждают сегодня