Comments 67
Интересно, чем же отличается от обычного обфускатора?
Сжатие и обфускация это разное, да.
если судить по скриншотам, то наверное тем, что оптимизируется только код, а имена функций остаются такими же. обфускатор, вроде бы, все функции тоже «оптимизирует» переименовывая в a(), b(), etc. делая код совершенно нечитаемым
нет, это просто разные степени «оптимизации», включаются дополнительным параметром командной строки
Поверьте, это сжатие. достаточно отформатировать код (чтобы не шел в одну строку) и все будет очень даже читабетельно.
Так же, есть обфускация и шифрование (криптованием это язык не повернется назвать).
обфускация редко когда будет меньше оригинала, т.к. чаще всего это код засраный реплейсами.
и будет он выглядеть примерно так:
дальше конечно только хуже, начиная char и base64, заканчивая RSA, с использованием динамических элементов шифрования:
вот примерно так, сорс код пытается себя защищать :) такие дела.
Так же, есть обфускация и шифрование (криптованием это язык не повернется назвать).
обфускация редко когда будет меньше оригинала, т.к. чаще всего это код засраный реплейсами.
и будет он выглядеть примерно так:
дальше конечно только хуже, начиная char и base64, заканчивая RSA, с использованием динамических элементов шифрования:
вот примерно так, сорс код пытается себя защищать :) такие дела.
правильный вопрос))
хотя отличия скорее есть, но не думаю что существенные и сильно выигрывает по сравнению с другим подобными онлайн-сервисами
хотя это все-таки продакшен-сервис…
но подается это новость как-будто гугл сделал что координальное
хотя отличия скорее есть, но не думаю что существенные и сильно выигрывает по сравнению с другим подобными онлайн-сервисами
хотя это все-таки продакшен-сервис…
но подается это новость как-будто гугл сделал что координальное
Ну надеемся скоро Google откроет исходный код еще нескольких своих интереснейших проектов, например GFS ;)
Минимизация кода — понятно. А где тут заявленая оптимизация?
ну так короче имена переменных, меньше памяти и так далее
хехе, уменьшение потребления памяти путём сокращения имён переменных % )
ну не совсем)
рассмотрим это:
в результате получаем:
то есть как минимум под лишние переменные память не выделяется. Уже приятно. packer такого не делает.
рассмотрим это:
function hello(name) {
var code = 19;
var srt = 'dss';
alert('Hello, ' + name);
}
hello('New user');
в результате получаем:
function hello(a){alert("Hello, "+a)}hello("New user");
то есть как минимум под лишние переменные память не выделяется. Уже приятно. packer такого не делает.
«Оптимизация размера»
не дописали… =)
не дописали… =)
единственный пример оптимизации, который я у них видел — function inlining: вызовы некоторых очень простых функций заменяются на их код, типа
(function(){ alert(123) })() заменится на alert(123)
на мой взгляд эффект от этого сомнительный
ещё в доках предлагается описывать в спецкомментариях тип каждой переменной, что теоретически даст «компилятору» возможность лучше оптимизировать код, но подтверждения этому я не нашёл
(function(){ alert(123) })() заменится на alert(123)
на мой взгляд эффект от этого сомнительный
ещё в доках предлагается описывать в спецкомментариях тип каждой переменной, что теоретически даст «компилятору» возможность лучше оптимизировать код, но подтверждения этому я не нашёл
The ADVANCED_OPTIMIZATIONS level goes beyond simple shortening of variable names in several ways, including:
* more aggressive renaming:
Compilation with SIMPLE_OPTIMIZATIONS only renames the note parameters of the displayNoteTitle() and unusedFunction() functions, because these are the only variables in the script that are local to a function. ADVANCED_OPTIMIZATIONS also renames the global variable flowerNote.
*dead code removal:
Compilation with ADVANCED_OPTIMIZATIONS removes the function unusedFunction() entirely, because it is never called in the code.
* function inlining:
Compilation with ADVANCED_OPTIMIZATIONS replaces the call to displayNoteTitle() with the single alert() that composes the function's body. This replacement of a function call with the function's body is known as «inlining». If the function were longer or more complicated, inlining it might change the behavior of the code, but the Closure Compiler determines that in this case inlining is safe and saves space. Compilation with ADVANCED_OPTIMIZATIONS also inlines constants and some variables when it determines that it can do so safely.
ну да, как я и написал, фактически кроме inlining оптимизации по скорости нет, а этот способ даёт выигрыш только на очень большом числе вызовов
Опять же не более, чем уменьшение размера.
Ну так в этом и фишка. У них там в факе вопрос примерно такой: «Есть ли какой-нибуть tradeoff между скоростью и размером файлов в выхлопе компилятора?» и они честно отвечают, что основная задача — уменьшить код, т.к. это увеличивает скорость загрузки страницы и всякое такое прочее. Ну и побочным эффектом _может_ стать небольшое увеличение производительности, т.к. «usually less code means faster code» как-то так.
Я конечно, понимаю что использование win1251 нынче не кашерно, но вот именно с ним у данного оптимизатора (тот что доступен через веб), наблюдаются проблемы (
я так поняла, что утилита делает минимизацию javascript'a. А как она оптимизирует код?
compiler.jar не запускается… по-моему compiler-latest.zip поврежден
Туда можно добавить несколько js файлов и толза вернет один собранный =)
Проверял в вебе
Размер без сжатия: 137.92 КБ
yuicompressor 2.4.2
97.5 КБ (32.7 КБ после gzip)
Google Closure Compiler (simple):
97.1 КБ (31.8 КБ после gzip)
Google Closure Compiler (advanced):
79,4 КБ
Но в simple режиме что-то с кодировкой, судя по комментам сверху это можно преодолеть, а вот js прогнанный через advanced mode вообще не заработал. Возможно дело в том, что я изначально слил несколько js файлов в один.
Попробую его наверное :)
Размер без сжатия: 137.92 КБ
yuicompressor 2.4.2
97.5 КБ (32.7 КБ после gzip)
Google Closure Compiler (simple):
97.1 КБ (31.8 КБ после gzip)
Google Closure Compiler (advanced):
79,4 КБ
Но в simple режиме что-то с кодировкой, судя по комментам сверху это можно преодолеть, а вот js прогнанный через advanced mode вообще не заработал. Возможно дело в том, что я изначально слил несколько js файлов в один.
Попробую его наверное :)
Если есть строковые ссылки на функции — они не находятся, в итоге функции оптимизируются как не использованние. Размер уменьшается, код не работает. Чтобы advanced работал нормально, нужно сделать дополнительные телодвижения: code.google.com/closure/compiler/docs/api-tutorial3.html#dangers
Так вот как получается та нечитабельная хренотень в скриптах гугла!.. :)
да, прогонял на jQuery — выигрыш после gzip еще 5%
Что если при использовании подобных методов сжатия, уже в рабочем коде обнаруживается ошибка?
тогда нужно исправить, потом занового сжать и только потомы выкладывать на сервер. Может кто-нибудь подскажет как можно оптимизировать этот процесс? может быть можно производить такое сжатие на лету?
тогда нужно исправить, потом занового сжать и только потомы выкладывать на сервер. Может кто-нибудь подскажет как можно оптимизировать этот процесс? может быть можно производить такое сжатие на лету?
тяжеловато такое будет на лету делать.
У нас минимизация делается при nightly build'e и все ошибки сборки высылаются скриптом на емейл.
У нас минимизация делается при nightly build'e и все ошибки сборки высылаются скриптом на емейл.
В своём проекте я держу каждый JS для отдельного модуля в отдельном файле. И при изменении одного из них (Определяет скрипт с некоторой периодичностью) собираю все файлы в один, прогоняю через yuicompressor и копирую на live. Тжс и с CSS
в частности для django это решается очень просто через django-compress, думаю подобные инструменты есть и для других фреймворков
соберите соотв. систему для перехода от delevoping-версии к продукту
мы, например, начинали с подвешивания хука на свн
мы, например, начинали с подвешивания хука на свн
Пишите скрипты для размещения. Или юзайте готовые решения, например, Capistrano
Можно делать сжатие на лету с помощью их API: code.google.com/intl/ru/closure/compiler/docs/gettingstarted_api.html
Хм, почему все while'ы заменяются на for'ы :)
Спасибо за ссылку — либа сжала код на 4% лучше YUI compressor.
Жаль с русским языком не дружит, если написать например:
результатом будет:
if (document.getElementById('comment_content_'+idFeedback)) {
document.getElementById('comment_content_'+idFeedback).innerHTML='комментарий был удален';
}
результатом будет:
а у меня при advanced optimization показывает пустую строку
Compiled Size: 0 bytes
Compiled Size: 0 bytes
Original Size: 2.87KB (1.11KB gzipped)
Compiled Size: 0 bytes (20 bytes gzipped)
Saved 100.00% off the original size (98.25% off the gzipped size)
Compiled Size: 0 bytes (20 bytes gzipped)
Saved 100.00% off the original size (98.25% off the gzipped size)
Любителям ужимать код js хочу заметить, что для того, что бы код был максимально сжимаемым, нужно следовать рекомендациям ADsafe.
А если не любители, а профессионалы, то используйте Продвинутые оптимизации, учитывая экспорты и экстерны ;)
github.com/troolee/jscc Вот начал набрасывать тулз. Описывается «проект» с помощью yaml. Что-то типа такого:
На выходе сжатый кложуром яваскрипт. Есть режим --watch: тулза мониторит изменения исходников и автоматом пережимает. Она еще в «зачаточном» состоянии, сыроватая, но вроде как работает.
Зависимости: closure, python, pyyaml. Пишется/проверяется под ubuntu.
api_version: 1
source_dir: src
output_dir: js
default_compilation_level: simple
targets:
output_filename-1.js:
compilation_level: advanced
sources:
- input-1.1.js
- input-1.2.js
- input-1.3.js
output_filename-2.js:
sources:
- input-2.1.js
- input-2.2.js
На выходе сжатый кложуром яваскрипт. Есть режим --watch: тулза мониторит изменения исходников и автоматом пережимает. Она еще в «зачаточном» состоянии, сыроватая, но вроде как работает.
Зависимости: closure, python, pyyaml. Пишется/проверяется под ubuntu.
Sign up to leave a comment.
Оптимизация Javascript с помощью Google Closure Compiler