Так как изображение выполнено в серых цветах, то для определения яркости точки я использовал яркость красной составляющей RGB, поделенную на 32. Таким образом, максимально возможный сдвиг равен 255/32 = 7.
Прочитал, удивился, снова посмотрел на картинку — и действительно: если присмотреться, можно увидеть ступеньки :-)
а ещё на домашней страничке минимизируемого проекта нету никаких сотен килобайт графики. и jpeg'а фоном тоже нету. да мне просто больше нечего минимизировать! :-D
Ну тут дело в том, что обратиться к переменной a одинаково затратно, как и обратиться к переменной _myMagicVariable. А вот вызывать дополнительную функцию, которая будет вместо меня обращаться к переменной — уже дороже.
В примерах я заменял код на равнозначный по сложности.
Если забить на скорость, то много чего ещё можно повыкидывать. Но так не интересно :-)
Про this и false я уже объяснял чуть выше. Суть в том, что интерпретатор гораздо быстрее резолвит ключевые слова, чем имена переменных. Когда мы обращаемся к переменной, интерпретатор лезет в скоп и перебирает все переменные до тех пор, пока не найдёт ту, которая называется так, как мы запросили, и возвращает значение. Это называется линейный поиск. В случае с ключевыми словами этого не происходит, поэтому их не переименовывают при минимизации.
можно после loop statement поставить запятую и расположить все операторы из statements через запятую(вместо точки с запятой) — экономим 2 байта(фигурные скобки)
— верно, но это подходит только для простых случаев (без например ифов внутри). Но один такой фор я всё-же нашёл
if(i.length>0)
смело заменяем на if(i.length)
тоже 2 байта
— тоже да; забавно, что я описал это в топике, но забыл заметить в коде :-)
в коде дважды встречается [0,0,0,0,0,0] — логично вынести в отдельную переменную, даст еще 11 байт
— нет, это массив, он должен быть разным в каждом случае
опережая будущих комментаторов: замену a.charAt(0) на a[0] делать не стоит, т.к. ведет к потере ie6
— в моём конкретном случае поддержка ie6 уже убита («благодаря» window.postMessage и script.onload), так что, пожалуй, воспользуюсь
— экономит на использовании typeof. Но строка «undefined» толще, чем «typeof» :-) или это должно увеличить производительность?
Ещё в функциях из одного ифа отлично использовать тернарник.
Имеется в виду только случай if (a) return b; else return c;? В моём коде такого нет… Если с помощью тренарного оператора можно как-то по-другому сэкономить на if-else — подскажите, я наверное туплю сейчас и не вижу :-)
я уверен, людей которые составляли эту спецификацию скоро отпустит, и они поймут, что так кодить нельзя :-)
находим период, и по соседним секциям восстанавливаем смещения — получаем исходную чёрно-белую картинку :-)
Прочитал, удивился, снова посмотрел на картинку — и действительно: если присмотреться, можно увидеть ступеньки :-)
хотя, да. топик не про минимайзеры.
а ещё на домашней страничке минимизируемого проекта нету никаких сотен килобайт графики. и jpeg'а фоном тоже нету. да мне просто больше нечего минимизировать! :-D
да, тут нужно поразбираться…
Но я за собой заметил, что с некоторого времени почти спокойно воспринимаю и отлаживаю минифицированный код :-D
Шутка. GCC сработал, конечно, лучше, но предварительная оптимизация всё же улучшила результат на полкилобайта.
Но в любом случае, это пост не про минимайзеры, а про подготовку кода к минимизации. По идее, эти советы минимайзеро-независимы…
В примерах я заменял код на равнозначный по сложности.
Если забить на скорость, то много чего ещё можно повыкидывать. Но так не интересно :-)
Про this и false я уже объяснял чуть выше. Суть в том, что интерпретатор гораздо быстрее резолвит ключевые слова, чем имена переменных. Когда мы обращаемся к переменной, интерпретатор лезет в скоп и перебирает все переменные до тех пор, пока не найдёт ту, которая называется так, как мы запросили, и возвращает значение. Это называется линейный поиск. В случае с ключевыми словами этого не происходит, поэтому их не переименовывают при минимизации.
— верно, но это подходит только для простых случаев (без например ифов внутри). Но один такой фор я всё-же нашёл
— тоже да; забавно, что я описал это в топике, но забыл заметить в коде :-)
— нет, это массив, он должен быть разным в каждом случае
— в моём конкретном случае поддержка ie6 уже убита («благодаря» window.postMessage и script.onload), так что, пожалуй, воспользуюсь
итого: ещё 9 байт сэкономил
— экономит на использовании typeof. Но строка «undefined» толще, чем «typeof» :-) или это должно увеличить производительность?
Имеется в виду только случай if (a) return b; else return c;? В моём коде такого нет… Если с помощью тренарного оператора можно как-то по-другому сэкономить на if-else — подскажите, я наверное туплю сейчас и не вижу :-)