Thanks Stephan for the uber descriptive explanation. Very helpful.
On Sep 11, 4:24 pm, Stephan Beal <[EMAIL PROTECTED]> wrote:
> On Sep 12, 12:59 am, "Web Specialist" <[EMAIL PROTECTED]>
> wrote:
>
> > I'm using Jorn's Form Validation in a monster form. Using jQuery
> > 1.2minified version returns all validation in =~ 16 sec. Using
> > uncompressed
> > version returns in 6 sec. Comparing with an older version I don't have any
> > improvement.
>
> That speed difference is almost certainly caused by odd circumstances,
> not by the compression. A minified jQuery version is semantically
> identical to an uncompressed version. A MIN'd copy essentially only
> has whitespaces and comments removed, and those are meaningless for
> the JS engine, which means they have no effect on execution speed.
> During the JS compilation phase, only meaningful tokens are converted
> to bytecode for the JS interpreter, while whitespace and comments are
> literally stripped out. Now... if you have a really odd JS engine
> which does not compile the source code to bytecode (or recompiles it
> on each call) then i could understand a menial speed diff between
> MIN'd and uncompressed code, but i would be surprised if any
> commercial JS engine out there does that.
>
> A packed version is decompressed at the time the outer-most code is
> run (when jQuery is first included), after which the compression
> overhead is gone. This means that PACKing only has an overhead at load-
> time (which may or may not be less than the time it would take to
> transfer an unpacked copy). It has no effect on the execution speed of
> the JS code once the initial expansion is done, however.
>
> If your MIN'd code is using YUIMin (as opposed to Doug Crockford's
> jsmin), then it is functionally similar to the conventional PACK
> process, in that it will have an initial overhead while the code is
> unpacked, but afterwards the bytecode engine will have uncompressed
> code and the decompression will play no role on the execution speed.
