DCE Update

[Nicolas Cannasse]

Hi,

I've mostly rewritten dead code elimination (DCE) implementation in the
compiler r4214. This should allow finer control and allow us to fix the
small bugs that were still unresolved.

I did some tests with the new implementation and things seems good so
far, but I would be interested if some of you could compile+test your
code with --dead-code-elimination to see how well it works.

In the near future, my idea is to have it as default for JS target, and
allow for the JS output to only add things such as reflection support
when the corresponding methods are used/compiled, in order to have very
small .js files when doing some very simple things.

Best,
Nicolas

[Franco Ponticelli]

Wonderful, I'll test it ASAP. I am pretty sure that if wr can make it work on my project it means that it will be pretty solid.

Franco

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
>

[Franco Ponticelli]

In my code I have a reference to this class:

class RSAEncrypt implements IBlockCipher { ... }

where IBlockCipher is a plain interface.

When I compile without DCE I get this generated (in JS):

chx.crypt.RSAEncrypt.__interfaces__ = [chx.crypt.IBlockCipher];

But when I compile with DCE I get this:

chx.crypt.RSAEncrypt.__interfaces__ = [Dynamic];

Which obviously fails because Dynamic is not defined.

Franco

[Franco Ponticelli]

The new DCE works pretty impressively. I think there is still an issue for variables of type function passed as arguments but I've not been able to isolate the problem in a small sample. In any case I've been able to trim 23% of fat from my JS library ;)

Franco

[postite]

DCE compression is great !

i noticed an error when using polygonal DLL . targetting javascript with __dead-code-elimination

"Dynamic is not referenced"

just to say !

[Franco Ponticelli]

That the same problem I had when interfaces were discarded. For me it was fixed a few commits ago.

Franco

[Michael Baczynski]

Hi,

Nicolas has already fixed this in rev. 4220 :)

best,
michael

[postite]

yes it works great !!

finally i can use datastructures for lightweight js output !

coolissime 

[Tom]

Hi Nicolas!
This is good new!

Maybe some recent windows nigtly build wolud be cool. ;)

[Simon Krajewski]

After finally getting around to run a comparison, here are the results:

platform: without DCE -> with DCE (delta%)
swf8: 20kb -> 17kb (-15%)
swf9: 26kb -> 21kb (-19%)
js: 113kb -> 99kb (-13%)
neko: 99kb -> 81kb (-18%)
php: 157kb -> 138kb (-12%)
cpp: 1.107kb -> 1.033kb (-7%)

I like it!
Simon

[Juraj Kirchheim]

I am curious to know: What did you compile? :)

[Simon Krajewski]

The selecthxml unit tests. There's little custom code to optimize away
there, so above results should roughly reflect the amount of haxe std
stuff you save with DCE.

Simon

[dean....@gmail.com]

I added --dead-code-elimination to my project (JS target) and get an assert from the compiler

Z:\Projects\servers\ampcompo>C:\Motion-Twin\haxe\haxe.exe .\compile.hxml -D release 

File "codegen.ml", line 1279, characters 87-93: Assertion failed

Build halted with errors.

Done(1)

Compiles fine without it, not a small code base so going to be hard to cut down into a repo case.

Deano

[Nicolas Cannasse]

Le 28/03/2012 20:53, dean....@gmail.com a �crit :

> I added --dead-code-elimination to my project (JS target) and get an
> assert from the compiler
>
> Z:\Projects\servers\ampcompo>C:\Motion-Twin\haxe\haxe.exe .\compile.hxml
> -D release
> File "codegen.ml", line 1279, characters 87-93: Assertion failed
> Build halted with errors.
> Done(1)

Could you report it there : http://code.google.com/p/haxe/issues ?

Thanks,
Nicolas

[Nicolas Cannasse]

Le 28/03/2012 20:53, dean....@gmail.com a �crit :

> I added --dead-code-elimination to my project (JS target) and get an
> assert from the compiler
>
> Z:\Projects\servers\ampcompo>C:\Motion-Twin\haxe\haxe.exe .\compile.hxml
> -D release
> File "codegen.ml", line 1279, characters 87-93: Assertion failed
> Build halted with errors.
> Done(1)
>
> Compiles fine without it, not a small code base so going to be hard to
> cut down into a repo case.

Should be fixed in r4350

Best,
Nicolas

[Baluta Cristian]

It's not working in any of my projects, how can i manually mark a function to not be removed?

One of the problems is HXAddress, it has this kind of initialization:

static var _initializer = _initialize();

None of the _initializer or _initialize exists in my js.

On Thu, Mar 29, 2012 at 6:25 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Best,
Nicolas

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--
Băluță Cristian
http://ralcr.com
http://imagin.ro

[Franco Ponticelli]

@:keep

Franco

[Michiel Crefcoeur]

Please don't make DCE default behaviour for JS, at least not when a JS Generator macro is being used.

It will break dependency injection features of JSTM and the follow-up libraries I'm working on right now.

Applying IoC patterns will become alot less useful if modules can not be dynamicly injected anymore because of possibly eliminated code.

Also, if it's default behavior, shouldn't it then be the default for all targets? (except when a JS generator is used)

Best,

Michiel

On Sunday, March 4, 2012 1:58:07 PM UTC+1, Nicolas Cannasse wrote:

[Franco Ponticelli]

I don't think it will be default behavior ... the default behavior will be adding --js-modern.

In any case remember that you can always add @:keep using a macro that is called into your compilation file. That way you don't have to decide in the code if you want to keep or not.

Franco

--

[Nicolas Cannasse]

Le 17/04/2012 18:58, Franco Ponticelli a �crit :

> I don't think it will be default behavior ... the default behavior will
> be adding --js-modern.
> In any case remember that you can always add @:keep using a macro that
> is called into your compilation file. That way you don't have to decide
> in the code if you want to keep or not.

I would like ot make it the default so we can showcase Haxe as a
almost-zero-overhead to-javascript compiler.

A lot of potential JS users will look at how HelloWorld.hx is generated.
If it takes too much JS output, they will - wrongly - assume that it
will not scale well.

Best,
Nicolas

[Stephane Le Dorze]

I totally agree here.

On Tue, Apr 17, 2012 at 7:36 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Best,
Nicolas

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--

Stéphane Le Dorze

http://lambdabrella.blogspot.com/

http://www.linkedin.com/in/stephaneledorze

http://twitter.com/stephaneledorze

Tel: +33 (0) 6 08  76 70 15

[Franco Ponticelli]

I agree on the sample but adding -dce to it doesn't seem that bad .... or maybe DCE could be enabled by default if there is -main but turned off if not?

Franco

[mic...@incloud.nl]

I think we can all agree that the standard JS bootstrap code introduces too much overhead which will always be just dead code for a Hello World program.

The reason why standard JS bootstrap is so big right now is because Haxe currently requires too much static initialisation which JSTM solves by using runtime dependency injection.

So yes, using DCE will, as a side-effect, trim down the bootstrap code but as a result, advanced JS generator features will be doomed. :-(

About the scaling part: I got that one covered for you ;-)

Best,

Michiel

Op dinsdag 17 april 2012 20:36:54 UTC+2 schreef Nicolas Cannasse het volgende:

Le 17/04/2012 18:58, Franco Ponticelli a �crit :

[Nicolas Cannasse]

Le 18/04/2012 19:16, mic...@incloud.nl a �crit :

> I think we can all agree that the standard JS bootstrap code introduces
> too much overhead which will always be just dead code for a Hello World
> program.
> The reason why standard JS bootstrap is so big right now is because Haxe
> currently requires too much static initialisation which JSTM solves by
> using runtime dependency injection.
> So yes, using DCE will, as a side-effect, trim down the bootstrap code
> but as a result, advanced JS generator features will be doomed. :-(

You still will be able to disable DCE of course ;)

Best,
Nicolas

[Baluta Cristian]

Question, when we remove traces, can be the pos.Infos be removed as well? Or maybe a new flag if people use it for other things than debug.

On Wed, Apr 18, 2012 at 10:16 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Best,
Nicolas

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

[Baluta Cristian]

This DCE is great, i lowered my js from 355kb to 285 and 270 without traces. It's far from the swf which has about 100 but anyway...

[Philippe Elsass]

Does it work with Google Closure compiler? Even simple optimization can reduce weight nicely.

Philippe

[Nicolas Cannasse]

Le 19/04/2012 13:20, Philippe Elsass a écrit :
> Does it work with Google Closure compiler? Even simple optimization can
> reduce weight nicely.

--js-modern activates strict mode and should work with Google Closure.

Best,
Nicolas

[Franco Ponticelli]

It works very well with Google Closure.

Franco

Best,
Nicolas