[SPAM] - Re: Re: [Soot-list] Help (fwd) - Email found in subject

[Philippe Laporte]

Hi,
   Thanks for your answer.

I have in mind the fact that the code produced by javac is not so
optimized, be it speed or size-wise.

Suppose the compiler is generating the code for such a Java construct as

local_var = expression ;


following its invariants, it would produce


E
Dup
i/astore

then

pop


obviously this can be reduced to 

E
i/astore


I.e., I am speaking of peep-hole optimizations. The assumption being
that javac is not too good at it.

Such optimizations go towards code-size reductions. Does JShrink do
them? I'm sure Soot does...

It will be interesting to see how JBCO compares with Proguard and
YGuard. All the best with that effort!

I'm in search of the ultimate pipeline :-):

best compiler | best code optimizer | best obfuscator

I'm not sure if the first one is important given the second one. Also
not sure of the order between the second and third ones.

I understand the size vs speed tradeoff global situation is complex...we
kindof need both inlining and smallest size :-)


Thanks a lot,

Philippe Laporte


-----Original Message-----
From: soot-list-bounces at sable.mcgill.ca
[mailto:soot-list-bounces at sable.mcgill.ca] On Behalf Of
mbatch at cs.mcgill.ca
Sent: 18 mai 2007 15:59
To: soot-list at sable.mcgill.ca
Subject: [SPAM] - Re: Re: [Soot-list] Help (fwd) - Email found in
subject

On Fri, May 18, 2007 3:30 pm, Philippe Laporte wrote:
> I've just used SOOT to process my J2ME-CLDC app.
>
> The total size has increased, and I have not been yet able to measure
> any performance improvements.

The reality is that you may not see any performance improvements. Some
applications might see small improvements and others might see some
slowdowns. Furthermore, the more latent a program the less bump you'll
see
for obvious reasons.

Soot performs a lot of different transformations. Some will result in
negative performance gains due to the specific code in question.

> Can we expect a size increase with all speed increases (inlining?)

Certainly, some optimizations will increase the size of the program -
especially inlining. However, not all will and I do not think there is
any
option to enable only those that reduce size.

> I think the J2ME-CLDC community should be most enthusiastic about
> using SOOT in a SOOT | obfuscator pipeline.

You may try Java bytecode shrinking tools such as JShrink if size is a
big
factor for you (as it seems it would be) but I suspect you know this
already. Additionally, Soot now has an obfuscating module called JBCO
which performs some pretty interesting and new obfuscations, many of
which
have very limited size and performance penalties.

Cheers,

Michael

_______________________________________________
Soot-list mailing list
Soot-list at sable.mcgill.ca
http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list