I can't add much to what Ben and Henry have said:
For space optimization, our compiler already 'compresses' the
Javascript emitted using the same techniques as Dojo's
'Shrinksafe' (although with our own compiler). It does not go to the
extreme of some of the compressors out there because we feel they go
overboard trying to compress the code at a cost in startup time
required for the browser to unpack the code. Enabling compression on
your server will have the same effect but the compression/
decompression will be in native server/client code rather than
interpreted javascript.
Optimizations to reduce code size that we have not done, which could
be considered:
1. Abbreviating private API's.
2. Dropping unreachable code.
Because Javascript has `eval`, which _could_ in theory call any API,
doing either of these optimizations could potentially break things.
We would need to tighten up our private API declarations to do this
correctly.
As Ben has also pointed out, speed optimization is still in the
future and will be based on careful profiling.
On 2007-06-12, at 13:00 EDT, Henry Minsky wrote:
Let us not forget that making sure that compression is enabled in
your web server for the lzx and js files will make the download
size substantially smaller.
On 6/12/07, Benjamin Shine <[EMAIL PROTECTED]> wrote: Hi, Can.
We're focused on making the object/event/view/network code solid,
portable, and fast; I don't think we are currently planning on more
optimizations to the compiler. The javascript emitted by the open
laszlo compiler already has variable name compression and whitespace
trimmming. If you look at the code, you'll see bigLongVariableName
becomes $1.
Michael A. Jackson's rules of optimization steer us here:
1. Don't do it.
2. (for experts only) Don't do it yet.
Tucker has taught me that this means, "Don't optimize until you have
a clear solution, and don't optimize until you know where the
performance bottlenecks lie." Wikipedia is helpful here... http://
en.wikipedia.org/wiki/Optimization_(computer_science)
That said... it sounds like you're interested in optimizing for
download size. Is that right? I bet optimization for download size
could be improved by a careful look at what libraries and components
are included by the compiler by default. In the 12000 lines of
javascript that a small compiile produces, there are probably a few
unneeded inclusions.
If you're interested in optimizing for runtime performance, that
would be a different thing. Optimization for runtime performance
should (imho) only be done after vicious profiling; otherwise, how
would you know where to optimize? My benchmarking work so far reveals
that runtime performance is very different in the different browsers,
so then you get into optimizing for a particular runtime. At this
point in the development cycle of OL4, it's too early for that; we
need higher quality and consistency across runtimes more than we need
per-runtime performance optimizations.
And with all that said... a few places in the code have already been
hand-tweaked; I'm thinking in particular of the CSS engine, in which
Adam Wolff inlined some function calls. That was for code that we
*knew* was being called over and over at startup time, and we had
benchmarks in place to test the optimizations.
It would be interesting to see what a javascript optimizer does with
the emitted code; feel free to give it a try and let us know what you
learn. Or clarify exactly what you're trying to optimize *for*, and
we can advise you further.
-ben
On Jun 12, 2007, at 8:14 AM, Can Barışcan wrote:
> are there plans , or anybody has tried optimizing the javascript
> code for dhtml runtime, and the app javacript(like gmail has). I
> beleive they have to be optimized with the same optimizer because
> they may use similar names for variables. Any good optimizer you
> know of that could shrink the js code, shorten the variable names
> and reduce the file size?
> Thanks,
> Can
Benjamin Shine
Software Engineer, Open Laszlo / Laszlo Systems
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
