Pull to refresh

Comments 31

Супер! Я для собственных модулей подобные оптимизации проделываю. Т.е. this помещаю в self, лишь для того, чтобы uglifyjs мог эту переменную потом утоптать. При таком подходе код не теряет читаемость, но хорошо жмется. Общие функции забрасываю в области замыкания для того-же.

Спасибо! Да, в минификации модулей есть и свои особенности. Здесь я, конечно, модули не использовал, чтобы не тратить место на require или что-то подобное: было ощущение, что каждый байт на счету.
Я такое извращение в Кукараче только проделывал, чтобы сократить длину кода. Только преподавательница не могла прочитать мой код, так что пришлось делать его читаемым и повторяемым.
Вы не пишете самое главное: какая разница получается после gzip.
Там и не используется gzip, финальный файл пакуется в zip-архив. Я написал в посте, что размер index.html был 31.9 Кб, а в виде архива занял 10.1 Кб.
Но без некоторых оптимизаций, приведённых в посте он был бы меньше в zip, или важен именно несжатый вариант?

Важен размер именно zip-файла.

this.this.this.this.
var s=this;s.s.s.s.

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

Ну, лишнего кода там — три символа: две кавычки и плюс. А вот ерунду, к сожалению, писал изначально, так что версии без неё нет. Но на следующий раз принял к сведению, создам две версии и буду их при сжатии сравнивать.

размер zip-архива с этим файлом не должен превышать 13 килобайт;
Как ни смешно, но большая часть этих оптимизаций для сжатия оказалась излишней: даже с оригинальными именами глобальных переменных файл с игрой превратился в zip-архив размером 10.1 Кб (при размере index.html в 31.9 Кб).

Такими оптимизациями влегкую можно подкузьмить архиватору и вызвать увеличение размера архива.

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

А зачем вам вообще this? Просто ModuleName_setSomeProp(itemObj, '..value..') и так далее, жаться будет на ура, читаемость отличная, даже работать будет быстрей.

Если честно, вообще не понял, что за ModuleName_setSomeProp(itemObj, '..value..').

Без архиватора было бы спортивнее: с этими сокращениями он, вероятнее, лучше справится. И еще: а если через обфускатор прогнать? Я ими не пользовался, но думаю, что с определенными настройками он код короче делает…

Да, я тоже думаю, что без архиватора, чистым текстом, было бы интереснее. Но — таковы правила, ничего не попишешь. Пробовал через packer, он сжимает до ~21 Кб, но с ошибками. Разбираться было некогда, да и есть опасения, что с такими наворотами может начать тормозить.

Видимо организаторы исходят из того что практически все серверы и броузеры поддерживают дефлейт. А вот на мой взгляд спортивнее было бы если бы после загрузки и парсинга код отъедал не более 13 кбайт в оперативке /pokerface Дом и сам движок не считаем.

Такие условия слишком сложны для проверки. Нужно держать каждую игру запущенной (и играть в неё) довольно длительное время, чтобы удостовериться в объёмах используемой памяти. Что касается deflate, на сайте выкладывается разархивированная версия, так что в браузер попадает просто html-файл.

Самый первый кусок кода показывает, как нельзя делать минификатор. Замена подстроки this на s сломала логику — вторая строка будет эквивалентна this.s.s.s а не this.this.this.this.

Уверен, что автор это понимает и в продакшен-коде подобной ошибки бы не допустил, но все же пример стоит сделать более наглядным.

Первый кусок кода — только для сравнения длин строк. Это вообще не рассматривается как рабочий код. Смысл в том, чтобы наглядно показать, сколько символов будут занимать четыре обращения к this и четыре обращения к переменной.


this.x=0;this.y=1;this.w=2;this.h=3;
var s=this;s.x=0;s.y=1;s.w=2;s.h=3;

Вариант с переменной короче на один символ при четырёх обращениях к объекту. Каждое следующее обращение будет экономить ещё по три символа.

А мне вот это понравилось https://github.com/agar3s/devil-glitches
Например, в одном из конструкторов было 39 штук this. Заменив их на self, получилось сэкономить более 100 байт.

Но как?
В том комментарии this напрямую превращается в s. А в статье превращением this в self экономятся килобайты.

В процессе минификации self превратится в s. То есть, полная цепочка будет выглядеть так:


this.x = 0; this.y = 1; this.w = 2; this.h = 3; // код с this
var self = this; self.x = 0; self.y = 1; self.w = 2; self.h = 3; // this заменили на self
var s=this;s.x=0;s.y=1;s.w=2;s.h=3; // при минификации self стал одним символом
Честно говоря не знаю, какой алгоритм использует zip для сжатия. Но думаю можно подобрать имена так, что бы получался хороший вариант сжатия. Не понятно, почему не считать размер просто исходника.

Возможно, организаторы решили, что 13 Кб исходников — слишком мало для интересных игр. А было бы намного интереснее. Вон, люди пишут замечательные демки на JS в пределах 1 Кб.

Прикольная заморочка.

Читал про это, но решил не использовать, так как потом всё равно в zip-архив нужно упаковать, а я сомневаюсь, что PNG бы сильно сжался. К тому же, только в этом году разрешили эту фичу использовать.

*Почти offtop:* для любителей подобных соревнований есть ещё 1k Intro (http://archive.assembly.org/2016/1k-intro), но там несколько хардкорней — ассемблер, бутсектор, крутые демо.
Sign up to leave a comment.

Articles