This flag actually has no effect in javac other than letting the compiler inline constants. (It's JIT in the JVM at runtime that does most of the optimization.) I'm actually surprised it had any observable effect here, and wonder if this is consistently reproducible?
I certainly favor setting this flag; there's no real reason not to. Real byte-code optimization comes from ProGuard. I use it constantly but had to remove it from our build because I don't think Maven plays nice with it and maybe there are license issues. It's a real shame to lose performance because of stuff like that. The speed bump varied, but was up to about 10% IIRC. Not bad. On Fri, Sep 4, 2009 at 12:00 PM, Robin Anil<robin.a...@gmail.com> wrote: > I saw that the maven compile:compile plugin didnt have the optimize=true > enabled for mahout > so i ran an experiment. Forget about the machine specs. Its run on the same > system > > Before enabling optimize: > Compile Time > Core : 50 secs > Examples 10 secs > FPGrowth 50K transactions with minSupport 20% > Time taken: 1:40 min > > After enabling optimize > Compile TIme > Core: 1:08 min > Examples: 20 secs > FPGrowth 50K transactions with minSupport 20% > Time taken: 1:28 min > > There seem to be some improvement in speed. > > > Any thoughts or comments on this. Or on java optimizations in general > > Robin > > Wishing Java had a -O3 >
