How good is the optimiser in the EWB compiler? If I write code like:

fBucketTick := (ScalePanel.Width - SCALE_BAR_OFFSET - SCALE_BAR_OFFSET);

Is it able to take those two Const values and make them a single value at compile
time? I'm not expecting an amazing optimiser, but am hoping that it can do these
simple ones. It's a long time since I wrote a compiler, so I haven't been able to
say "directed acyclic graph" at parties for a while. 8-)

/Matthew Jones/

On 12/20/2013 10:37 AM, (Matthew Jones) wrote:
> How good is the optimiser in the EWB compiler? If I write code like:
>
> fBucketTick := (ScalePanel.Width - SCALE_BAR_OFFSET - SCALE_BAR_OFFSET);
>
> Is it able to take those two Const values and make them a single value at compile
> time? I'm not expecting an amazing optimiser, but am hoping that it can do these

Not at this time as per quick test. Since we're generating JS you can
see the end result by opening the resulting file.

Most of the optimization AFAIK currently done is to eliminate code that
is never called thus reducing the JS size.

Considering the EWB app is run by the JS engine in the browser there
might be additional optimizations done at that execution time.

At the rate JS engines are improving my vote goes for more features and
then optimize later when need arises.

Raul

Matthew,

<< How good is the optimiser in the EWB compiler? If I write code like:

fBucketTick := (ScalePanel.Width - SCALE_BAR_OFFSET - SCALE_BAR_OFFSET);

Is it able to take those two Const values and make them a single value at
compile time? >>

1.03 does constant folding for strings (don't ask), but I can probably
squeeze in integers and Booleans.  In general, I don't try to modify the
original code too much so that it's somewhat recognizable in the various
browser debuggers.  Otherwise, it makes debugging difficult.  I should
probably combine the compression option with these other types of
optimizations, because when the code is compressed, it can't be debugged
anyways.

Tim Young
Elevate Software
www.elevatesoft.com