Синтаксическое улучшение производительности
При программировании мы сталкиваемся с различными проблемами. И есть так много решений тоже. Среди них мы выбираем лучшее решение производительности. Критерии производительности могут быть изменены из-за ограничений и сред, нехватки памяти или пула ЦП. Итак, мы исследуем временную сложность и пространственную сложность алгоритма. Обычно мы принимаем лучший алгоритм временной сложности. После того, как мы примем алгоритм наилучшей временной сложности, можем ли мы еще улучшить производительность?
Другой процесс, тот же результат
В предыдущей статье я сравнил крошечную разницу в производительности между быстрой сортировкой и сортировкой в куче. Он имеет разницу в производительности, которая не влияет на временную сложность из-за операций SWAP. Результат сортировки тот же, но есть разница в производительности. На самом деле, когда у нас есть лучшее решение временной сложности, мы больше не оптимизируем. Однако его также можно оптимизировать для факторов, влияющих на очень небольшую производительность. Другими словами, если подход к решению проблем принципиально одинаков, он использует другой синтаксис или использует другие реализации для повышения производительности.
Например, давайте посмотрим на пол с плавающей запятой. Существуют различные методы для пола с плавающей запятой в javascript. Используйте объект Math или вызовите функцию parseInt или используйте логические операции.
Math.floor(7/2) // 3 parseInt(7/2) // 3 7/2 | 0 // 3 ~~(7/2) // 3
Все четыре метода одинаковы, но процесс отличается. В чем разница между этими четырьмя методами? Я тестирую на jsperf.com, чтобы увидеть разницу в производительности
Высокий уровень операций в секунду означает быстрый код. Math.floor функция самая быстрая. Но не имеет значительного разрыва по сравнению с tildes и or.
Это действительно влияет на производительность?
Пример нижнего предела с плавающей запятой имеет относительно большие различия в производительности. parseInt и Math.floor отличаются более чем в 10 раз. Но есть так много случаев, которые имеют крошечные различия
Сравнение с итераторами не имеет больших отличий. Но по сравнению с ними, они обречены быть быстрыми и медленными. Это крошечные различия и производительность. Это означает, что если сильно сократить производительность, изменив синтаксис, можем ли мы хотя бы немного повысить производительность? И действительно ли мы должны это делать? На мой взгляд, это от случая к случаю.
Не нужно рассматривать
Не нужно учитывать маленькую производительность практически в любых условиях. Аппаратные характеристики лучше, чем раньше. Так что не нужно этих усилий. И почти на производительность внешнего интерфейса влияет поведение пользовательского интерфейса, вызывающее рендеринг. Как могут вызываться функции reflow и repaint. Анимация тоже не при чем. когдаrequestAnimationFrame вызывается повторно, вызываемые функции достаточно легкие, чтобы поддерживать 60 кадров в секунду. И спецификации оборудования также достаточно, чтобы помочь. Если вы измените код синтаксически, чтобы немного повысить производительность, читабельность вашего кода может ухудшиться. Вы можете потерять большие вещи, беспокоясь о мелкой производительности.
Необходимо рассмотреть
Javascript больше не только для клиента. Его можно использовать для обработки больших данных и ответов на огромные запросы от клиентов на сервере. Это может быть серверный язык. Следовательно, необходимо поднять производительность до предела, чтобы сделать хороший продукт как для сервера, так и для клиента. Кроме того, javascript можно запускать на оборудовании с плохими характеристиками, которое не похоже на ПК и смартфон. В системе с низкими характеристиками для обеспечения хорошей производительности не только оптимизируйте работы рендеринга, но и оптимизируйте коды. Если когда-либо сделать немного более высокую производительность, она может почувствовать большую разницу в среде низкого уровня, чем в среде высокого класса.
На мой взгляд…
На мой взгляд, я согласен, не нужно рассматривать как 7 против 3. Почти люди не считают маленькую производительность, кроме тех, у кого есть одержимость производительностью. На самом деле, если учесть улучшение синтаксической производительности, это может привести к потере читабельности кода. Я думаю, это большая потеря. Но есть немного жадности. Потому что все хотят выжать производительность.
