Aaron, I would like the jar file... I want to integrate this packer along with my ant build script...
-GTG On 7/14/07, Aaron Porter <[EMAIL PROTECTED]> wrote:
I just ran some tests against the current version from SVN to see how fast they load on my machine. Firefox 2.0.0.4 on Linux: jquery.js (original uncompressed) - 158243 bytes: 66ms jquery.pack.js - 21585 bytes: 129ms jquery.compressed.js (my compressor) - 17005 bytes: 394ms IE6 on XP under VMWare on the same Linux machine: jquery.js (original uncompressed) - 158243 bytes: 15ms jquery.pack.js - 21585 bytes: 62ms jquery.compressed.js (my compressor) - 17005 bytes: 171ms On a 56K modem my version will be faster on the first load then the packed version will be faster on subsequent loads. It all depends on what you're after. I haven't made the source available yet but that's something I'm considering. I'll need to clean it up first. I could get you a jar file (it's written in Java) if you're interested. Aaron Michael Geary wrote: > Sounds interesting, Aaron, thanks for the pointer. > > Two questions: > > How is the unpacking speed? I don't care how long it takes to pack the code > (within reason), but unpacking speed is very important, especially on slow > machines like an iPhone/Nokia/Windows Mobile phone. I saw a test report that > seemed to indicate that Dean's packer took 1.5 seconds to unpack jQuery on > the iPhone, which is way too slow. I would gladly take a slower packing time > to get faster unpacking. > > Is the source code available? I can't use a compressor that I have to go to > a website to use. That's fine for testing, but for production use I need to > be able to integrate it into my build process and have it available at all > times. > > Thanks, > > -Mike > > >> From: Aaron Porter >> >> I know Dean Edward's packer has already been suggested but >> you can try my compressor if you'd like: >> >> http://www.scriptingmagic.com/Topics/Compression/JavaScript%20Compressor/ >> >> My compressor is slower than packer but the results will be >> smaller. It also doesn't have a problem with things like >> missing semi-colons at the end of lines because it uses Rhino >> for the first pass which cleans everything up. >> > >
