javascript output optimization.

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

javascript output optimization.

sledorze
Hi!
Looking at javascript code generated by the compiler, I see a lot of boilerplate (it looks like the optimization has been done on a more general phase and not on the javascript generation one).
Looks like nothing is made to make it particularly fast nor small (looks like it's made for debug purpose).
I wonder if there's some options so that the output is generated for optimized code / space?
Stephane
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
eh.
As Marc pointed out..
eh..
remove debug is a good idea..
eh.. stupid me.

Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

danielku15
In reply to this post by sledorze
Additionally you can use code optimizers/minimizers like Google Closure Compiler, JsMin or Yahoo Javascript Compressor. I'm using the Google Closure Compiler to optimize the code which removes unneeded elements,  dead code and simplifies local variable names. (and a lot more)  
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
danielku15 wrote:
> Additionally you can use code optimizers/minimizers like Google Closure
> Compiler, JsMin or Yahoo Javascript Compressor. I'm using the Google Closure
> Compiler to optimize the code which removes unneeded elements,  dead code
> and simplifies local variable names. (and a lot more)  

But it still leaves vast amounts to be desired, the javascript produced
isn't even "good" javascript and no amount of compilers will clean it up
or reduce it, although they do remove some of the unneeded braces and
shorten some variable names.

Haxe produces classes for interfaces(!) which adds a tonne of wait and
breaks NoInterface IDL constraints, the output is all over the place,
inheritance is done wrong, it /really/ pollutes the global name space,
it isn't compatible with non browser based runtimes, and even then the
js.* classes which attempt to do some DOM/browser related stuff are all
pretty much wrong and about 5% of what's needed.

Ack, in short the code produced is butt ugly, unoptimized, unstructured
and will scare off any js developer who looks at an all-in-a-file lib
that haxe produces - standard reaction is OMG <laugh>.

JS has been pretty much ignored as a target, it's like a pre-alpha "well
it works" target.

Compounding the issues, are that unlike the flash compiler which
produces optimized bytecode, the js compiler produces unoptimized proxy
or alternative js classes mixed in with haxes version of functionality
which is provided as standard by ecmascript-262 runtimes, which
essentially means that haxe code will always run slower on JS than non
haxe versions of the code (which use the native implementations of
functionality). Unless an alternative standard library is created which
targets JS only, matching and extern'ing the ecmascript-262 v3/v5
interfaces. But then this would be against the haxe mentality and ethos
of write once run anywhere and target multiple platforms.

So, sadly, even if the js target was worked on heavily, it'd always be
somewhat of a poor cousin to the other targets, and never be as good as
non haxe js code, unless made totally incompatible with the other haxe
targets.

Best,

Nathan

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

clemos
Hi Nathan,

On Sun, Nov 28, 2010 at 12:53 PM, Nathan <[hidden email]> wrote:

> So, sadly, even if the js target was worked on heavily, it'd always be
> somewhat of a poor cousin to the other targets, and never be as good as non
> haxe js code, unless made totally incompatible with the other haxe targets.
>

I agree there is still lots of work to be done on the js target.
First it should be made independent from a browser environnement. This
step seems easy, since it has already been done and proven possible
since haxe generated javascript can be used together with nodejs
(hxnode) or rhino (hxrhino). These projects also show how it's
possible to adapt haXe to JS platforms other than browsers.
Then, the haxe/js DOM API probably also needs some work. Currently the
js package is very poor because it's meant to be 100% platform
agnostic. Maybe it could be interresting to write some simple higher
level classes that would make it really cross-browser and complete. It
would be things like basic browser/feature detection, simple element
and events wrappers. In addition, the same way js.SWFObject is
implemented, we could write an extern class for CSS Selector (possibly
implementation-independant, so one could then embed either Sizzle,
Slick, ...). There could also be a few compiler flags for handling
backward compatibilty (or incompatibilty), with legacy IEs and things
like that, more or less the way base2 does it (compatibility with
IE5...).
Finally, the code generator itself maybe also needs compiler flags to
be implemented for platform specific optimisations.

I don't think all this would go against the haXe way. It would not
necessarily make it totally incompatible to other targets, but rather
widen the range of available JS platforms.

Cheers,
Clément

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
clemos wrote:

> Hi Nathan,
>
> On Sun, Nov 28, 2010 at 12:53 PM, Nathan <[hidden email]> wrote:
>
>> So, sadly, even if the js target was worked on heavily, it'd always be
>> somewhat of a poor cousin to the other targets, and never be as good as non
>> haxe js code, unless made totally incompatible with the other haxe targets.
>>
>
> I agree there is still lots of work to be done on the js target.
> First it should be made independent from a browser environnement. This
> step seems easy, since it has already been done and proven possible
> since haxe generated javascript can be used together with nodejs
> (hxnode) or rhino (hxrhino). These projects also show how it's
> possible to adapt haXe to JS platforms other than browsers.

Indeed, I also use blackdog's node library, certainly helps deploy to
nodejs.

> Then, the haxe/js DOM API probably also needs some work. Currently the
> js package is very poor because it's meant to be 100% platform
> agnostic. Maybe it could be interresting to write some simple higher
> level classes that would make it really cross-browser and complete. It
> would be things like basic browser/feature detection, simple element
> and events wrappers. In addition, the same way js.SWFObject is
> implemented, we could write an extern class for CSS Selector (possibly
> implementation-independant, so one could then embed either Sizzle,
> Slick, ...). There could also be a few compiler flags for handling
> backward compatibilty (or incompatibilty), with legacy IEs and things
> like that, more or less the way base2 does it (compatibility with
> IE5...).

Yup, I've actually already done all the DOM and webgl interfaces for
haxe, the lib is quite mature now, and full ecmascript-262 v3 and v5
compatibility libraries, unsure if and when they'll be released publicly
(although probably yes, and "soon") - the primary issue is that although
all the DOM/webgl interfaces are all haxe compatible, none of the
ECMAScript interfaces are (since they introduce Object and RegExp, align
Array/String with javascript, slightly conflict with lambda
functionality), those issues have been resolved tbh, but it requires
using a js-only std lib which isn't much good, and it can't be haxelib'd
as you can't overwrite the default root classes, and even if you could,
they'd be incompatible.

> Finally, the code generator itself maybe also needs compiler flags to
> be implemented for platform specific optimisations.

Certainly would - I've been in and modified the haxe compiler myself
already http://github.com/webr3/haxe to add packaged output and some
other tweaks, but creating proper nicely formatted output is a v
difficult job, and further aligning with js and dropping things like
interfaces output as classes will essentially kill rtti and reflection APIs.

> I don't think all this would go against the haXe way. It would not
> necessarily make it totally incompatible to other targets, but rather
> widen the range of available JS platforms.

I can assure you, that supporting the DOM or WebGL, or Node.js or Rhino
is possible, but exposing and aligning with ECMAScript-262 is
incompatible with other the targets, and also exposing the default
global context for each platform is also pretty much impossible without
adding something like my contexts proposal from earlier in the year.
Macro's don't particularly cut it - tried and failed on that one already.

Best,

Nathan

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

jlm@justinfront.net
In reply to this post by Nathan
Nathan

Actually I have had mainly fairly positive responses from javascript  
dev's but I don't think any have found the advantages compelling  
enough to start using it, but then many are not really used to full on  
OOP languages, they are used to hacking Mootools and jQuery and coping  
with browser quirks and really don't have time to learn another  
approach unless it really offers more ( and they don't care about the  
static typing etc... there used to javascript ).  Give them more  
tools...  Did you look at Ample SDK, could it easily be integrated  
with your work?  I really think components in haXe javascript would  
lift user numbers and then there would be more blogs, examples and  
contributors to the haXe javascript target.

Cheers

;j

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
I was coming back to the thread to post again about JS output quality (I am noob at JS but can see there's a problem) and just seen your posts.

I don't want to start a flame war but I think Action script will lost momentum in the future (and eventually die) due to the upcoming HTML5.. what will remain at adobe will be the tools set with different target flavors.

If haXe want to cope, it has to embrace more effectively the Javascript world (like others are starting to do) or will die with flash because there will be a better tool which provides static typing and output optimized/correct/compliant JS.

So having a good JS backend quality is fundamental - I understand that today, this is perhaps not the focus of the current developpers behind haXe (I can be wrong).
I don't know how the community and/or the haXe mainteners want to approach this adaptation challenge.

There's still some interest to look at what others are doing:
- What F# javascript generation looks like..
- Looking at how coffeescript tries to optimize the generated JS (even perhaps an opportunity to generate coffeescript and use its compiler to get the advantages it provides as a first step).

Glad to see this discussion happening,
Stephane Le Dorze


On Sun, Nov 28, 2010 at 2:22 PM, [hidden email] [via Haxe] <[hidden email]> wrote:
Nathan

Actually I have had mainly fairly positive responses from javascript  
dev's but I don't think any have found the advantages compelling  
enough to start using it, but then many are not really used to full on  
OOP languages, they are used to hacking Mootools and jQuery and coping  
with browser quirks and really don't have time to learn another  
approach unless it really offers more ( and they don't care about the  
static typing etc... there used to javascript ).  Give them more  
tools...  Did you look at Ample SDK, could it easily be integrated  
with your work?  I really think components in haXe javascript would  
lift user numbers and then there would be more blogs, examples and  
contributors to the haXe javascript target.

Cheers

;j

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5781626.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

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


Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
exactly, glad others are starting to see this too :)

sledorze wrote:

> I was coming back to the thread to post again about JS output quality (I am
> noob at JS but can see there's a problem) and just seen your posts.
>
> I don't want to start a flame war but I think Action script will lost
> momentum in the future (and eventually die) due to the upcoming HTML5.. what
> will remain at adobe will be the tools set with different target flavors.
>
> If haXe want to cope, it has to embrace more effectively the Javascript
> world (like others are starting to do) or will die with flash because there
> will be a better tool which provides static typing and output
> optimized/correct/compliant JS.
>
> So having a good JS backend quality is fundamental - I understand that
> today, this is perhaps not the focus of the current developpers behind haXe
> (I can be wrong).
> I don't know how the community and/or the haXe mainteners want to approach
> this adaptation challenge.
>
> There's still some interest to look at what others are doing:
> - What F# javascript generation looks like..
> - Looking at how coffeescript tries to optimize the generated JS (even
> perhaps an opportunity to generate coffeescript and use its compiler to get
> the advantages it provides as a first step).
>
> Glad to see this discussion happening,
> Stephane Le Dorze
>
>
> On Sun, Nov 28, 2010 at 2:22 PM, [hidden email] [via Haxe] <
> [hidden email]<ml-node%[hidden email]>
>> wrote:
>
>> Nathan
>>
>> Actually I have had mainly fairly positive responses from javascript
>> dev's but I don't think any have found the advantages compelling
>> enough to start using it, but then many are not really used to full on
>> OOP languages, they are used to hacking Mootools and jQuery and coping
>> with browser quirks and really don't have time to learn another
>> approach unless it really offers more ( and they don't care about the
>> static typing etc... there used to javascript ).  Give them more
>> tools...  Did you look at Ample SDK, could it easily be integrated
>> with your work?  I really think components in haXe javascript would
>> lift user numbers and then there would be more blogs, examples and
>> contributors to the haXe javascript target.
>>
>> Cheers
>>
>> ;j
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org <http://haxe.org?by-user=t>
>>
>>
>> ------------------------------
>>  View message @
>> http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5781626.html
>>
>> To unsubscribe from javascript output optimization., click here<
>>
>>
>
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
I think the difficulty is to keep a single shared vision.
Explaining is a first step, I hope it won't last too much before action (oh, but, I could code this instead of speaking!!! ah.. no, got work to do for a living.. sad..)

On Sun, Nov 28, 2010 at 3:20 PM, Nathan [via Haxe] <[hidden email]> wrote:
exactly, glad others are starting to see this too :)

sledorze wrote:

> I was coming back to the thread to post again about JS output quality (I am
> noob at JS but can see there's a problem) and just seen your posts.
>
> I don't want to start a flame war but I think Action script will lost
> momentum in the future (and eventually die) due to the upcoming HTML5.. what
> will remain at adobe will be the tools set with different target flavors.
>
> If haXe want to cope, it has to embrace more effectively the Javascript
> world (like others are starting to do) or will die with flash because there
> will be a better tool which provides static typing and output
> optimized/correct/compliant JS.
>
> So having a good JS backend quality is fundamental - I understand that
> today, this is perhaps not the focus of the current developpers behind haXe
> (I can be wrong).
> I don't know how the community and/or the haXe mainteners want to approach
> this adaptation challenge.
>
> There's still some interest to look at what others are doing:
> - What F# javascript generation looks like..
> - Looking at how coffeescript tries to optimize the generated JS (even
> perhaps an opportunity to generate coffeescript and use its compiler to get
> the advantages it provides as a first step).
>
> Glad to see this discussion happening,
> Stephane Le Dorze
>
>
> On Sun, Nov 28, 2010 at 2:22 PM, [hidden email] [via Haxe] <
> [hidden email]<[hidden email]>
>> wrote:

>
>> Nathan
>>
>> Actually I have had mainly fairly positive responses from javascript
>> dev's but I don't think any have found the advantages compelling
>> enough to start using it, but then many are not really used to full on
>> OOP languages, they are used to hacking Mootools and jQuery and coping
>> with browser quirks and really don't have time to learn another
>> approach unless it really offers more ( and they don't care about the
>> static typing etc... there used to javascript ).  Give them more
>> tools...  Did you look at Ample SDK, could it easily be integrated
>> with your work?  I really think components in haXe javascript would
>> lift user numbers and then there would be more blogs, examples and
>> contributors to the haXe javascript target.
>>
>> Cheers
>>
>> ;j
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org <http://haxe.org?by-user=t>
>>
>>
>> ------------------------------
>> To unsubscribe from javascript output optimization., click here<
>>
>>
>
>
>
View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5781708.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

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


Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Justin Donaldson-3
In reply to this post by Nathan
Hi Nathan,

I've run into a few of the issues that you're mentioning below, but I'm not sure if I agree with the characterization of the javascript target as "pre-alpha".  You did a great job outlining the problems, but I think "pre-alpha" isn't a fair evaluation of the haxe js target, if only because many of the js applications you want to implement (node.js) are themselves relatively new implementations of javascript.


On Sun, Nov 28, 2010 at 3:53 AM, Nathan <[hidden email]> wrote:

But it still leaves vast amounts to be desired, the javascript produced isn't even "good" javascript and no amount of compilers will clean it up or reduce it, although they do remove some of the unneeded braces and shorten some variable names.

The compilers themselves aren't perfect, and might be considered "beta" themselves:
http://webreflection.blogspot.com/2009/11/google-closure-im-not-impressed.html
http://code.google.com/p/haxe/issues/detail?id=220#c0

A properly functioning compiler will reduce the size though... perhaps not as much as handwritten javascript code, but I've found I can get at least 25-50% in most cases with yuic.

 

Haxe produces classes for interfaces(!) which adds a tonne of wait and breaks NoInterface IDL constraints,

The interfaces are there for reflection, as you note elsewhere.  I'm not familiar with the NoInterface IDL though... and can't find anything through searching.  What's the story there?
 
the output is all over the place, inheritance is done wrong, it /really/ pollutes the global name space, it isn't compatible with non browser based runtimes, and even then the js.* classes which attempt to do some DOM/browser related stuff are all pretty much wrong and about 5% of what's needed.
 
The output is all over the place mainly because the compiler is inserting things into the js file based on dependency and initialization requirements.  Check the placement of __init functions, etc.  I thought things made sense, even if the classes themselves were not alphabetically organized, etc.


Ack, in short the code produced is butt ugly, unoptimized, unstructured and will scare off any js developer who looks at an all-in-a-file lib that haxe produces - standard reaction is OMG <laugh>.


Perhaps, but this isn't really fair, is it?  Nobody looks at the haxe generated swf byte code and calls it ugly.  The generated js code is essentially meant to be treated as "compiled code" that doesn't get inspected except perhaps for debug purposes.  You certainly wouldn't want to edit the compiled js output either.

 
Compounding the issues, are that unlike the flash compiler which produces optimized bytecode, the js compiler produces unoptimized proxy or alternative js classes mixed in with haxes version of functionality which is provided as standard by ecmascript-262 runtimes, which essentially means that haxe code will always run slower on JS than non haxe versions of the code (which use the native implementations of functionality). Unless an alternative standard library is created which targets JS only, matching and extern'ing the ecmascript-262 v3/v5 interfaces. But then this would be against the haxe mentality and ethos of write once run anywhere and target multiple platforms.

I haven't run into major speed issues yet, but I know you've done some performance evaluations... at least in as3.  Where are the major speed issues in the js target?
Secondly, isn't this the sort of situation that conditional compilation (with __js__ magic) is designed for?  Where are the opportunities to address the speed differences?  And better yet, can we fix some existing bugs in javascript this way?:
http://stackoverflow.com/questions/850341/workarounds-for-javascript-parseint-octal-bug

Best,
-Justin


--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
Justin Donaldson wrote:
> Hi Nathan,
>
> I've run into a few of the issues that you're mentioning below, but I'm not
> sure if I agree with the characterization of the javascript target as
> "pre-alpha".  You did a great job outlining the problems, but I think
> "pre-alpha" isn't a fair evaluation of the haxe js target, if only because
> many of the js applications you want to implement (node.js) are themselves
> relatively new implementations of javascript.

Yup, I guess it was a bit harsh, however it's nothing to do with
node.js, I'm talking specifically ECMAScript-262 which has been a
standardized language since 1999, long before haxe afaict.

> On Sun, Nov 28, 2010 at 3:53 AM, Nathan <[hidden email]> wrote:
>
>> But it still leaves vast amounts to be desired, the javascript produced
>> isn't even "good" javascript and no amount of compilers will clean it up or
>> reduce it, although they do remove some of the unneeded braces and shorten
>> some variable names.
>>
>
> The compilers themselves aren't perfect, and might be considered "beta"
> themselves:
> http://webreflection.blogspot.com/2009/11/google-closure-im-not-impressed.html
> http://code.google.com/p/haxe/issues/detail?id=220#c0
>
> A properly functioning compiler will reduce the size though... perhaps not
> as much as handwritten javascript code, but I've found I can get at least
> 25-50% in most cases with yuic.

Yup, I opt for closure (simple optimizations only) to quickly clean up
the multiple braces issues and then I completely restructure/rewrite by
hand and move to maintaining via pure js, once I know the cores
technically sound and type safe that is. Not much of a PITA.

>> Haxe produces classes for interfaces(!) which adds a tonne of wait and
>> breaks NoInterface IDL constraints,
>
>
> The interfaces are there for reflection, as you note elsewhere.  I'm not
> familiar with the NoInterface IDL though... and can't find anything through
> searching.  What's the story there?

http://www.w3.org/TR/WebIDL/#NoInterfaceObject
Many web specs require that you add [NoInterfaceObject] to classes, the
whole point being so you don't pollute the global namespace, so let's
say you do "typeof Document" in js, you'll get 'undefined', because it's
an interface and not a class - however, with haxe that'd be a 'object'
because the interfaces are defined.

Particular thorn in my side because I'm doing the reference
implementation for one of the HTML5 specs I edit, and thus can't use
haxe for it, so had to compile then port all code over to js.

And, obviously, rtti or no rtti, having full interfaces output really
isn't nice at all, there's got to be other approaches, even a nice
little map closure namespaced off would do the trick.

>> the output is all over the place, inheritance is done wrong, it /really/
>> pollutes the global name space, it isn't compatible with non browser based
>> runtimes, and even then the js.* classes which attempt to do some
>> DOM/browser related stuff are all pretty much wrong and about 5% of what's
>> needed.
>>
>
> The output is all over the place mainly because the compiler is inserting
> things into the js file based on dependency and initialization
> requirements.  Check the placement of __init functions, etc.  I thought
> things made sense, even if the classes themselves were not alphabetically
> organized, etc.

It's not a requirement of the compiler to dump out all static members
towards the end of the file, and to have classes in a different order
each compile, or indeed everything in one file - that can certainly
easily be changed.

>> Ack, in short the code produced is butt ugly, unoptimized, unstructured and
>> will scare off any js developer who looks at an all-in-a-file lib that haxe
>> produces - standard reaction is OMG <laugh>.
>>
> Perhaps, but this isn't really fair, is it?  Nobody looks at the haxe
> generated swf byte code and calls it ugly.  The generated js code is
> essentially meant to be treated as "compiled code" that doesn't get
> inspected except perhaps for debug purposes.  You certainly wouldn't want to
> edit the compiled js output either.

Completely and utterly fair imho, JS is all about having open accessible
code which people can read, and especially when your releasing js
libraries and code for the general web public - saying "oh I used haxe"
doesn't forgive it in the eyes of the masses, it makes them think haxe
is a pile of .. you know. And thus, rewriting from scratch in js or
editing the compiled output /is/ the only option, unless you're doing
some closed source private project for a site which nobodies every going
to look at or care about that is.

There a massive issue of maintenance as well, just because /you/ (or I)
haxe, doesn't mean to say the next decades worth of developers who have
to maintain the code are haxe devs, they have to work with the
/compiled/ code - would you like to do that?

>> Compounding the issues, are that unlike the flash compiler which produces
>> optimized bytecode, the js compiler produces unoptimized proxy or
>> alternative js classes mixed in with haxes version of functionality which is
>> provided as standard by ecmascript-262 runtimes, which essentially means
>> that haxe code will always run slower on JS than non haxe versions of the
>> code (which use the native implementations of functionality). Unless an
>> alternative standard library is created which targets JS only, matching and
>> extern'ing the ecmascript-262 v3/v5 interfaces. But then this would be
>> against the haxe mentality and ethos of write once run anywhere and target
>> multiple platforms.
>>
>
> I haven't run into major speed issues yet, but I know you've done some
> performance evaluations... at least in as3.  Where are the major speed
> issues in the js target?

Primarily, haxe doesn't make use of much of the native runtime
implemented functionality, of the language constructs such as for - I
know that when haxe is compiling avm2 bytecode it can make some
optimizations and come out tops (or expose some "hidden" op codes which
access fast mem), but when it's trying to compete home grown js source
code against native constructs on runtimes which have over a decades
worth of the best engineers in the world optimizing them, it's quite
obvious it can't compete.

The issues is that because haxe is multi target, it can only make use of
a subset of functionality and constructs used across all targets, and
then add on it's own compiler features (like enums and typedefs), in
some scenarios it augments the target perfectly, providing all target
features and adding more (like flash) and in others it looses masses of
functionality, fights against the language and doesn't play well at all
(js) - there's a big difference between spitting out bytecode and
spitting out source code, haxe does one well, the other not so.

> Secondly, isn't this the sort of situation that conditional compilation
> (with __js__ magic) is designed for?

doesn't that defeat the purpose of using haxe in the first place? btu
no, not really the __js__ magic doesn't cover it, nor does conditional
compilation, because the issue is in the std classes and language
constructs output by the compiler for the js target.

> Where are the opportunities to address the speed differences?

std/*.hx and in the js compiler.

> And better yet, can we fix some existing bugs in javascript this way?:

"08" is octal, it's expected functionality, a gotcha for the
non-octal-aware at best.

Cheers,

Nathan

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Dion Amago
In reply to this post by Justin Donaldson-3
This thread is extremely interesting to me because I'm building a game
that needs to run in javascript.

My burning question is: how lacking in performance is the current JS
target (compared to optimized JS code) in comparison to rendering?

What I mean is: currently rendering is one of the main bottlenecks for
JS games.  The canvas element is quite slow, especially large canvas
elements continuously redrawn.  If rendering is the main bottleneck,
then a slight performance gain in non-rendering code is not much to
worry about.  However, if the difference is significant in comparison to
rendering times, then I'm concerned, and would like to know more, and
help improve the compiler if possible.

Does anyone have any numbers regarding optimized vs non-optimized code?

Dion


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nicolas Cannasse
In reply to this post by Nathan
Le 28/11/2010 12:53, Nathan a écrit :
> JS has been pretty much ignored as a target, it's like a pre-alpha "well
> it works" target.
[...]

I think you're being overly unfair on haXe/JS support.

I'm the first one to admit that it requires more work, and I've already
advanced on some of the things we have been discussing in the past.

For instance today I have committed the --macro compiler parameter
implementation which will enable macro-controlled compiler
configuration. A few uses cases can be :

- manage excluded classes, allowing for instance to exclude interfaces
from being generated
- allow custom .js splitting (per package, or using your own rules)
- ... and much more

I have also talked with Franco about ways to avoid putting things in the
global scope.

Instead of bashing haXe .js output, you should describe much more
precisely how the JS output can be made better, and detail why such
changes are important for JS developers.

Also, I don't agree with your claim that haXe high-level approach is
doomed to be less optimized, since

a) the code generated in methods is pretty much the same that one would
write in plain JS, but since we go through a compiler it can be
automatically optimized

b) using high-level constructs such as enums will enable the compiler to
do smart optimizations that the developer might not have done itself

This is the whole story of programming languages evolution - or else
everybody would still be coding in ASM/C

Nicoals

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

sledorze
I take this opportunity to say that the Js backend does not inline code..

On Sun, Nov 28, 2010 at 8:57 PM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 28/11/2010 12:53, Nathan a écrit :
> JS has been pretty much ignored as a target, it's like a pre-alpha "well
> it works" target.
[...]

I think you're being overly unfair on haXe/JS support.

I'm the first one to admit that it requires more work, and I've already
advanced on some of the things we have been discussing in the past.

For instance today I have committed the --macro compiler parameter
implementation which will enable macro-controlled compiler
configuration. A few uses cases can be :

- manage excluded classes, allowing for instance to exclude interfaces
from being generated
- allow custom .js splitting (per package, or using your own rules)
- ... and much more

I have also talked with Franco about ways to avoid putting things in the
global scope.

Instead of bashing haXe .js output, you should describe much more
precisely how the JS output can be made better, and detail why such
changes are important for JS developers.

Also, I don't agree with your claim that haXe high-level approach is
doomed to be less optimized, since

a) the code generated in methods is pretty much the same that one would
write in plain JS, but since we go through a compiler it can be
automatically optimized

b) using high-level constructs such as enums will enable the compiler to
do smart optimizations that the developer might not have done itself

This is the whole story of programming languages evolution - or else
everybody would still be coding in ASM/C

Nicoals

--
haXe - an open source web programming language
http://haxe.org



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5782389.html

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

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


Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Justin Donaldson-3
In reply to this post by Nathan


On Sun, Nov 28, 2010 at 11:07 AM, Nathan <[hidden email]> wrote:
[...]
Yup, I guess it was a bit harsh, however it's nothing to do with node.js, I'm talking specifically ECMAScript-262 which has been a standardized language since 1999, long before haxe afaict.


Yeah, there are going to be some differences from the spec, mainly because of target issues.  Different languages/targets have different base functionality (and limits) provided by "Object" instances (as one example).  Having a fast, spec compliant implementation for all targets just may not be possible.
 
[...]

Yup, I opt for closure (simple optimizations only) to quickly clean up the multiple braces issues and then I completely restructure/rewrite by hand and move to maintaining via pure js, once I know the cores technically sound and type safe that is. Not much of a PITA.

Yikes, that's way more effort than I would have the patience for.  What's your basic approach for rearranging the classes?
Also, on a related issue, you are aware of the javascript   --js-namespace prefix you can add to prevent haXe from polluting the base? (Also related the @native metadata tag which can be used to make haXe output using alternative namespace specs).
http://haxe.org/manual/metadata
 


Haxe produces classes for interfaces(!) which adds a tonne of wait and
breaks NoInterface IDL constraints,


The interfaces are there for reflection, as you note elsewhere.  I'm not
familiar with the NoInterface IDL though... and can't find anything through
searching.  What's the story there?

http://www.w3.org/TR/WebIDL/#NoInterfaceObject
Many web specs require that you add [NoInterfaceObject] to classes, the whole point being so you don't pollute the global namespace, so let's say you do "typeof Document" in js, you'll get 'undefined', because it's an interface and not a class - however, with haxe that'd be a 'object' because the interfaces are defined.

Particular thorn in my side because I'm doing the reference implementation for one of the HTML5 specs I edit, and thus can't use haxe for it, so had to compile then port all code over to js.

And, obviously, rtti or no rtti, having full interfaces output really isn't nice at all, there's got to be other approaches, even a nice little map closure namespaced off would do the trick.

Very cool about the html5 spec, and disappointing that the interfaces cause problems because of that.  Is it possible to exclude your interface specs with -exclude?  You'd be breaking haxe reflection, but you'd at least be able to produce some compliant code for your work.  I'm not familiar with the limitations and expectations at work here.

 


It's not a requirement of the compiler to dump out all static members towards the end of the file, and to have classes in a different order each compile, or indeed everything in one file - that can certainly easily be changed.

I'm not sure how/why the compiler reorganizes the classes this way. Since namespaces and classes are second class citizens (or a hack) in Javascript anyways, I can understand why it's so important to organize them as cleanly as possible in the js source.  My approach is to avoid looking at the js code when possible :)

 


Perhaps, but this isn't really fair, is it?  Nobody looks at the haxe
generated swf byte code and calls it ugly.  The generated js code is
essentially meant to be treated as "compiled code" that doesn't get
inspected except perhaps for debug purposes.  You certainly wouldn't want to
edit the compiled js output either.

Completely and utterly fair imho, JS is all about having open accessible code which people can read, and especially when your releasing js libraries and code for the general web public - saying "oh I used haxe" doesn't forgive it in the eyes of the masses, it makes them think haxe is a pile of .. you know. And thus, rewriting from scratch in js or editing the compiled output /is/ the only option, unless you're doing some closed source private project for a site which nobodies every going to look at or care about that is.


Yeah, that's true.  I probably wouldn't write a pure js library in haXe right now.  I might write the extern for it in haxe... and I've done quite a few... google maps, earth, facebook (js/as3) and a half complete jquery extern (before I found Andy's).  I know that you are deeply involved with the js community, but really the most viable option for haxe libraries is for other haxe developers to maintain them.  I realize this is not possible, but there's just not a good alternative, even with pretty js output.


 

There a massive issue of maintenance as well, just because /you/ (or I) haxe, doesn't mean to say the next decades worth of developers who have to maintain the code are haxe devs, they have to work with the /compiled/ code - would you like to do that?
 
Turning over maintenance to non-haxe users is the main problem.  The second you do that, the value of the code drops.  It's  a one-way ticket... I would not want to come back to an altered js source and try and recreate the haXe source from it.  I agree that "beautifying" js code would improve haxe in the eyes of js developers... at least in terms of them being agreeable to working with haXe generated code.  I doubt it would win over any converts, however. It also wouldn't alter the "one-way ticket" issue for turning over maintenance responsibilities.  I think this will always be a problem.


 


I haven't run into major speed issues yet, but I know you've done some
performance evaluations... at least in as3.  Where are the major speed
issues in the js target?

[...]

I need to play around with js performance on more platforms. Right now there is such a large amount of variance in the performance for different browsers.  Internet 6 needs to die, etc.  It's difficult to determine where the main bottlenecks/opportunities are for optimization. 



Where are the opportunities to address the speed differences?

std/*.hx and in the js compiler.


I was under the impression that you could use haxelib libraries to override base standard lib functionality, or am I just not getting your point?

 

And better yet, can we fix some existing bugs in javascript this way?:

"08" is octal, it's expected functionality, a gotcha for the non-octal-aware at best.

I agree that it's part of the js spec, but I don't think that it's expected functionality, at least in the principle of least surprise for someone who doesn't read specs before using a language.  It's also a bug for haXe in that parseInt in js differs from every other target's behavior. This problem really isn't relevant your criticisms, it's just a related issue that needs to get resolved for haXe for the sake of consistency.  I just mention it in passing.

Best,
-Justin

--
blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

John A. De Goes
In reply to this post by Nicolas Cannasse

Indeed, the use of types can actually allow more efficient code generation (dead code elimination, function inlining, etc.). Working at a higher level of abstraction sometimes allows higher performance.

In any case, I do agree that the code generator for the JS target can be improved. There are several distinct areas that can be improved:

1. Generate more natural JavaScript code, which eliminates unnecessary braces and parentheses.

2. Generate smaller JavaScript code. For example, there are many tricks that can be used to very efficiently construct class hierarchies. The current approach assigns each prototype, which takes up a lot of kbs.

3. Generate faster JavaScript code. For example, not wrapping a code block inside a function when no variables are captured.

4. Eliminating dead code, factoring out the standard library, splitting generated code by packages or in other ways.

 Finally, one might add "runtime class/package loading", but that's a more general feature which could be used in several other targets as well, and is significantly more complex.

Currently, my company sponsors Franco on (4), but that's just a small part of the overall puzzle. We need a JavaScript champion who can own (1) - (3). Someone who knows how to write efficient, fast JavaScript code, and isn't afraid to dig into the compiler to change the code generator.

Any volunteers? Nathan, I know you can do this. :-)

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Nov 28, 2010, at 12:55 PM, Nicolas Cannasse wrote:

Le 28/11/2010 12:53, Nathan a écrit :
JS has been pretty much ignored as a target, it's like a pre-alpha "well
it works" target.
[...]

I think you're being overly unfair on haXe/JS support.

I'm the first one to admit that it requires more work, and I've already advanced on some of the things we have been discussing in the past.

For instance today I have committed the --macro compiler parameter implementation which will enable macro-controlled compiler configuration. A few uses cases can be :

- manage excluded classes, allowing for instance to exclude interfaces from being generated
- allow custom .js splitting (per package, or using your own rules)
- ... and much more

I have also talked with Franco about ways to avoid putting things in the global scope.

Instead of bashing haXe .js output, you should describe much more precisely how the JS output can be made better, and detail why such changes are important for JS developers.

Also, I don't agree with your claim that haXe high-level approach is doomed to be less optimized, since

a) the code generated in methods is pretty much the same that one would write in plain JS, but since we go through a compiler it can be automatically optimized

b) using high-level constructs such as enums will enable the compiler to do smart optimizations that the developer might not have done itself

This is the whole story of programming languages evolution - or else everybody would still be coding in ASM/C

Nicoals

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

Nathan
In reply to this post by Nicolas Cannasse
Nicolas Cannasse wrote:
> Le 28/11/2010 12:53, Nathan a écrit :
>> JS has been pretty much ignored as a target, it's like a pre-alpha "well
>> it works" target.
>
> Instead of bashing haXe .js output, you should describe much more
> precisely how the JS output can be made better, and detail why such
> changes are important for JS developers.

Well, here's an outline of one tiny issue out of many.. but before I do,
I'm not knocking you Nicolas, or haxe directly, but , well we both know
the js support ain't great.

> a) the code generated in methods is pretty much the same that one would
> write in plain JS, but since we go through a compiler it can be
> automatically optimized

The native functionality provided by javascript engines isn't exposed by
haxe, instead haxe exposes custom functionality which matches it, for
instance let's go with something simple, Array.map() - haxe doesn't
expose this, it instead implements List and List.map(). Let's test it
with 3 lines of haxe:

1:  var x = new List<Int>();
2:  for(i in 0...1000000) x.add(i);
3:  var y = x.map( function(a) { return a/2; });

compiles to a 500 line js, but we can ignore that for now, on to the times!

line 2: 2355ms
line 3: 2160ms

and now the js version:

1:  var z = [];
2:  while(i++ < 1000000) z.push(i);
3:  var zy = z.map(function(a) {return a / 2;});

line 2: 85ms
line 3: 177ms

So, with haxe you've got a 4-5 second jam on the event loop, and thus a
5 second jam of the UI.

Or one could use "the great lambda" on an array and take advantage of at
least the native structure..

line 2: 91ms
line 3: 1964ms

Only a 2 second jam

So I guess one could start trying to make clever maps which detect and
use the native functionality in compiled code, but then you see many of
the interfaces and methods are mismatched, for instance Array.map()
takes closures with three params (element,index,array), whereas haxe
defines a map() which takes closure(element) and mapi which takes
closure(index,element). Haxe has a foreach which is something like an
Array.every and Array.forEach in js is something like .iter() in haxe,
but then .iter uses iterators of course rather than just the for
construct, and so it continues.

The problem is that the std/*.hx do not expose the core functionality of
the runtime, and instead use much (as you can see) slower userland code,
or have mismatched functionality, or simply doesn't expose it - it's the
interfaces that are wrong and that need to change, but then that's a
problem for the other targets - a mismatch.

So, there's one little illustration - I'd guess, if you can address that
simple 'map' case, then the rest can be worked at till the js target is
supported properly.

As you know, I've given it a go, and succeeded (perhaps not in
everybodies eyes ;), but it meant replacing std/ with a supports-only-js
std lib, and there are still some minor issues outstanding, global
contexts etc as you know.

Not much point discussing a whole host of things, so will leave it there,

Best,

Nathan

> b) using high-level constructs such as enums will enable the compiler to
> do smart optimizations that the developer might not have done itself
>
> This is the whole story of programming languages evolution - or else
> everybody would still be coding in ASM/C
>
> Nicoals
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

jlm@justinfront.net
surely you can supply us with native javascript arrays as part of a  
haXelib targeted at javascript, I don't see how they need or should  
replace the std library, but be more an addon library that could be  
used when optimization was needed, like say sugar.   Maybe I am  
missing the point but if you just want a different interface and  
variant base classes so you can create faster code then just create a  
haXelib?

On 28 Nov 2010, at 22:08, Nathan wrote:

> Nicolas Cannasse wrote:
>> Le 28/11/2010 12:53, Nathan a écrit :
>>> JS has been pretty much ignored as a target, it's like a pre-alpha  
>>> "well
>>> it works" target.
>> Instead of bashing haXe .js output, you should describe much more  
>> precisely how the JS output can be made better, and detail why such  
>> changes are important for JS developers.
>
> Well, here's an outline of one tiny issue out of many.. but before I  
> do, I'm not knocking you Nicolas, or haxe directly, but , well we  
> both know the js support ain't great.
>
>> a) the code generated in methods is pretty much the same that one  
>> would write in plain JS, but since we go through a compiler it can  
>> be automatically optimized
>
> The native functionality provided by javascript engines isn't  
> exposed by haxe, instead haxe exposes custom functionality which  
> matches it, for instance let's go with something simple, Array.map()  
> - haxe doesn't expose this, it instead implements List and  
> List.map(). Let's test it with 3 lines of haxe:
>
> 1:  var x = new List<Int>();
> 2:  for(i in 0...1000000) x.add(i);
> 3:  var y = x.map( function(a) { return a/2; });
>
> compiles to a 500 line js, but we can ignore that for now, on to the  
> times!
>
> line 2: 2355ms
> line 3: 2160ms
>
> and now the js version:
>
> 1:  var z = [];
> 2:  while(i++ < 1000000) z.push(i);
> 3:  var zy = z.map(function(a) {return a / 2;});
>
> line 2: 85ms
> line 3: 177ms
>
> So, with haxe you've got a 4-5 second jam on the event loop, and  
> thus a 5 second jam of the UI.
>
> Or one could use "the great lambda" on an array and take advantage  
> of at least the native structure..
>
> line 2: 91ms
> line 3: 1964ms
>
> Only a 2 second jam
>
> So I guess one could start trying to make clever maps which detect  
> and use the native functionality in compiled code, but then you see  
> many of the interfaces and methods are mismatched, for instance  
> Array.map() takes closures with three params (element,index,array),  
> whereas haxe defines a map() which takes closure(element) and mapi  
> which takes closure(index,element). Haxe has a foreach which is  
> something like an Array.every and Array.forEach in js is something  
> like .iter() in haxe, but then .iter uses iterators of course rather  
> than just the for construct, and so it continues.
>
> The problem is that the std/*.hx do not expose the core  
> functionality of the runtime, and instead use much (as you can see)  
> slower userland code, or have mismatched functionality, or simply  
> doesn't expose it - it's the interfaces that are wrong and that need  
> to change, but then that's a problem for the other targets - a  
> mismatch.
>
> So, there's one little illustration - I'd guess, if you can address  
> that simple 'map' case, then the rest can be worked at till the js  
> target is supported properly.
>
> As you know, I've given it a go, and succeeded (perhaps not in  
> everybodies eyes ;), but it meant replacing std/ with a supports-
> only-js std lib, and there are still some minor issues outstanding,  
> global contexts etc as you know.
>
> Not much point discussing a whole host of things, so will leave it  
> there,
>
> Best,
>
> Nathan
>
>> b) using high-level constructs such as enums will enable the  
>> compiler to do smart optimizations that the developer might not  
>> have done itself
>> This is the whole story of programming languages evolution - or  
>> else everybody would still be coding in ASM/C
>> Nicoals
>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: javascript output optimization.

jlm@justinfront.net
Its like I use native flash xml parsing because it's simpler and  
faster for me but if I wanted cross platform code I would use the  
standard haXe xml.
Standard libraries are for compatibility, if you need targeted library  
then it should atleast start as a haXelib.

On 28 Nov 2010, at 22:19, [hidden email] wrote:

> surely you can supply us with native javascript arrays as part of a  
> haXelib targeted at javascript, I don't see how they need or should  
> replace the std library, but be more an addon library that could be  
> used when optimization was needed, like say sugar.   Maybe I am  
> missing the point but if you just want a different interface and  
> variant base classes so you can create faster code then just create  
> a haXelib?
>
> On 28 Nov 2010, at 22:08, Nathan wrote:
>
>> Nicolas Cannasse wrote:
>>> Le 28/11/2010 12:53, Nathan a écrit :
>>>> JS has been pretty much ignored as a target, it's like a pre-
>>>> alpha "well
>>>> it works" target.
>>> Instead of bashing haXe .js output, you should describe much more  
>>> precisely how the JS output can be made better, and detail why  
>>> such changes are important for JS developers.
>>
>> Well, here's an outline of one tiny issue out of many.. but before  
>> I do, I'm not knocking you Nicolas, or haxe directly, but , well we  
>> both know the js support ain't great.
>>
>>> a) the code generated in methods is pretty much the same that one  
>>> would write in plain JS, but since we go through a compiler it can  
>>> be automatically optimized
>>
>> The native functionality provided by javascript engines isn't  
>> exposed by haxe, instead haxe exposes custom functionality which  
>> matches it, for instance let's go with something simple,  
>> Array.map() - haxe doesn't expose this, it instead implements List  
>> and List.map(). Let's test it with 3 lines of haxe:
>>
>> 1:  var x = new List<Int>();
>> 2:  for(i in 0...1000000) x.add(i);
>> 3:  var y = x.map( function(a) { return a/2; });
>>
>> compiles to a 500 line js, but we can ignore that for now, on to  
>> the times!
>>
>> line 2: 2355ms
>> line 3: 2160ms
>>
>> and now the js version:
>>
>> 1:  var z = [];
>> 2:  while(i++ < 1000000) z.push(i);
>> 3:  var zy = z.map(function(a) {return a / 2;});
>>
>> line 2: 85ms
>> line 3: 177ms
>>
>> So, with haxe you've got a 4-5 second jam on the event loop, and  
>> thus a 5 second jam of the UI.
>>
>> Or one could use "the great lambda" on an array and take advantage  
>> of at least the native structure..
>>
>> line 2: 91ms
>> line 3: 1964ms
>>
>> Only a 2 second jam
>>
>> So I guess one could start trying to make clever maps which detect  
>> and use the native functionality in compiled code, but then you see  
>> many of the interfaces and methods are mismatched, for instance  
>> Array.map() takes closures with three params (element,index,array),  
>> whereas haxe defines a map() which takes closure(element) and mapi  
>> which takes closure(index,element). Haxe has a foreach which is  
>> something like an Array.every and Array.forEach in js is something  
>> like .iter() in haxe, but then .iter uses iterators of course  
>> rather than just the for construct, and so it continues.
>>
>> The problem is that the std/*.hx do not expose the core  
>> functionality of the runtime, and instead use much (as you can see)  
>> slower userland code, or have mismatched functionality, or simply  
>> doesn't expose it - it's the interfaces that are wrong and that  
>> need to change, but then that's a problem for the other targets - a  
>> mismatch.
>>
>> So, there's one little illustration - I'd guess, if you can address  
>> that simple 'map' case, then the rest can be worked at till the js  
>> target is supported properly.
>>
>> As you know, I've given it a go, and succeeded (perhaps not in  
>> everybodies eyes ;), but it meant replacing std/ with a supports-
>> only-js std lib, and there are still some minor issues outstanding,  
>> global contexts etc as you know.
>>
>> Not much point discussing a whole host of things, so will leave it  
>> there,
>>
>> Best,
>>
>> Nathan
>>
>>> b) using high-level constructs such as enums will enable the  
>>> compiler to do smart optimizations that the developer might not  
>>> have done itself
>>> This is the whole story of programming languages evolution - or  
>>> else everybody would still be coding in ASM/C
>>> Nicoals
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
1234