javascript output optimization.

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

Re: javascript output optimization.

sledorze
Exactly.
Generic containers would be provided without knowing the implementation.
So the default would not have bad performance on each the platforms.

Specific containers would be used only coz you're binding to a native library.
 

On Mon, Nov 29, 2010 at 3:18 PM, Nathan [via Haxe] <[hidden email]> wrote:
Laurent Kappler wrote:
> I would be interested in a list of plateform specific optimisations.
> For exemple I didn't know using Array over List in Javascript would make
> such a huge difference.

Ideally you shouldn't have to know that using Array over List would make
a big difference, if you do know that, and start making target specific
optimizations, then it's going to be counter productive for your code on
other targets / or get you in to a big mess of #target switching.

The main speed difference will be gained by coding to interfaces, rather
than implementations, so not using array instead of list, but rather
still using list, and having list backed by several target specific
implementations.


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



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5784444.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.

Lars Madson
In reply to this post by Nathan
Le 29/11/2010 15:16, Nathan a écrit :
> Ideally you shouldn't have to know that using Array over List would
> make a big difference, if you do know that, and start making target
> specific optimizations, then it's going to be counter productive for
> your code on other targets / or get you in to a big mess of #target
> switching.
But I will be able to choose what's good for me and for the community,
which can definitely help on not being counter productive.
Instead of waiting for someone to do the holly optimisation work for me
one day.

Laurent

--
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 29/11/2010 15:16, Nathan a écrit :

> Laurent Kappler wrote:
>> I would be interested in a list of plateform specific optimisations.
>> For exemple I didn't know using Array over List in Javascript would
>> make such a huge difference.
>
> Ideally you shouldn't have to know that using Array over List would make
> a big difference, if you do know that, and start making target specific
> optimizations, then it's going to be counter productive for your code on
> other targets / or get you in to a big mess of #target switching.
>
> The main speed difference will be gained by coding to interfaces, rather
> than implementations, so not using array instead of list, but rather
> still using list, and having list backed by several target specific
> implementations.

This is already the case. For instance Neko has its own
haxe/std/neko/_std/List.hx which give the same API as the default
List.hx but with better performances.

I agree that each haXe class implementation should give the best
performances while keeping the specified behavior (and a reasonable
level of implementation complexity).

However not everybody do care about performances of each code line they
write (or else nobody would ever have written a single line of PHP
code). Some code is more performance-critical than other, and most of
the time one will simply share a part of the code between for instance
the JS/Flash client and the server and not the whole code.

So having informations such as "in Javascript, Array class is native so
provide the best speed" is indeed valuable for the haXe developer. The
community is welcome to provide such informations - baked with
reproducible benchmarks - in a section of the wiki to be created.

Nicolas

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

Re: javascript output optimization.

sledorze
IMHO, this is not very realistic for reusable cross platform code.

Think for instance about a path finding algorithm; to keep it optimal for Flash and JS.
One must to provide two implementations or rely heavily on abstraction (with oviously more complex implementation and possible uncompetitive performance lost), not mentionning having potentially more unit tests..

There's something not fitting the Vision here; It makes developping portable code harder than plateform specific one.
As humans usually take the least effort route, we'll get a lot of platform specific code.

IMHO, if we want to stick to that vision, we have to adress the challenges, not minimize them.

Stephane


P.S.: This is positive criticism and note that I really appreciate what you and the community have done so far.

On Mon, Nov 29, 2010 at 6:36 PM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 29/11/2010 15:16, Nathan a écrit :

> Laurent Kappler wrote:

>> I would be interested in a list of plateform specific optimisations.
>> For exemple I didn't know using Array over List in Javascript would
>> make such a huge difference.
>
> Ideally you shouldn't have to know that using Array over List would make
> a big difference, if you do know that, and start making target specific
> optimizations, then it's going to be counter productive for your code on
> other targets / or get you in to a big mess of #target switching.
>
> The main speed difference will be gained by coding to interfaces, rather
> than implementations, so not using array instead of list, but rather
> still using list, and having list backed by several target specific
> implementations.
This is already the case. For instance Neko has its own
haxe/std/neko/_std/List.hx which give the same API as the default
List.hx but with better performances.

I agree that each haXe class implementation should give the best
performances while keeping the specified behavior (and a reasonable
level of implementation complexity).

However not everybody do care about performances of each code line they
write (or else nobody would ever have written a single line of PHP
code). Some code is more performance-critical than other, and most of
the time one will simply share a part of the code between for instance
the JS/Flash client and the server and not the whole code.

So having informations such as "in Javascript, Array class is native so
provide the best speed" is indeed valuable for the haXe developer. The
community is welcome to provide such informations - baked with
reproducible benchmarks - in a section of the wiki to be created.

Nicolas

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



View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5785228.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.

Niel Drummond-3
I've been told to weigh into the discussion, though I must admit the arguments are not that new.

That the haXe std containers have diverging performance on different platforms is known , comparing List with Array on haXe-js is just silly. List is also slow on PHP and flash - so what ? Some containers are there for one target only, as far as I'm concerned they should be documented that way.

haxe js-Array is fast - Google's closure will not optimise code like the following:

for(var i=0; i<a.length; i++)
{
  // do something
}

which is still something I see most javascript programmers do.

The argument that the std library on js in its current state is mediocre is not unfounded, there isn't massive amounts that is useful there - i/o is constrained, browser APIs are somewhat limited, most containers should be avoided.

For me, the compiler brings type safety and a sane programming paradigm. Once you work on medium sized websites with 10K LOC javascript files, maintainability becomes a serious issue. The size of files should be pretty irrelevant, most browsers accept gzipped js files, haXe should market for large deployments where it's current feature set appeals, focusing on best practice development and fast turnaround (unlike GWT, which is dog slow).

Though I would agree that:

- the Std library should be replaceable in its entirety, and be installable through haxelib. Anything else would stifle innovation in the community.

- Niel

On 11/29/10 19:38, sledorze wrote:
IMHO, this is not very realistic for reusable cross platform code.

Think for instance about a path finding algorithm; to keep it optimal for Flash and JS.
One must to provide two implementations or rely heavily on abstraction (with oviously more complex implementation and possible uncompetitive performance lost), not mentionning having potentially more unit tests..

There's something not fitting the Vision here; It makes developping portable code harder than plateform specific one.
As humans usually take the least effort route, we'll get a lot of platform specific code.

IMHO, if we want to stick to that vision, we have to adress the challenges, not minimize them.

Stephane


P.S.: This is positive criticism and note that I really appreciate what you and the community have done so far.

On Mon, Nov 29, 2010 at 6:36 PM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 29/11/2010 15:16, Nathan a écrit :

> Laurent Kappler wrote:

>> I would be interested in a list of plateform specific optimisations.
>> For exemple I didn't know using Array over List in Javascript would
>> make such a huge difference.
>
> Ideally you shouldn't have to know that using Array over List would make
> a big difference, if you do know that, and start making target specific
> optimizations, then it's going to be counter productive for your code on
> other targets / or get you in to a big mess of #target switching.
>
> The main speed difference will be gained by coding to interfaces, rather
> than implementations, so not using array instead of list, but rather
> still using list, and having list backed by several target specific
> implementations.
This is already the case. For instance Neko has its own
haxe/std/neko/_std/List.hx which give the same API as the default
List.hx but with better performances.

I agree that each haXe class implementation should give the best
performances while keeping the specified behavior (and a reasonable
level of implementation complexity).

However not everybody do care about performances of each code line they
write (or else nobody would ever have written a single line of PHP
code). Some code is more performance-critical than other, and most of
the time one will simply share a part of the code between for instance
the JS/Flash client and the server and not the whole code.

So having informations such as "in Javascript, Array class is native so
provide the best speed" is indeed valuable for the haXe developer. The
community is welcome to provide such informations - baked with
reproducible benchmarks - in a section of the wiki to be created.

Nicolas

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



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

To unsubscribe from javascript output optimization., click here.



--
Stéphane Le Dorze

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




View this message in context: Re: javascript output optimization.
Sent from the Haxe mailing list archive at Nabble.com.


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

Re: javascript output optimization.

Nathan
Hi Niel,

Wise words, it's a good job you were told/asked to chip in :)

inline from here..

Niel Drummond wrote:
>  I've been told to weigh into the discussion, though I must admit the
> arguments are not that new.
>
> That the haXe std containers have diverging performance on different
> platforms is known , comparing List with Array on haXe-js is just silly.

Have to disagree, they're both in the root of std and core haxe API
classes so equally valid to use, haxe developers shouldn't have to be
aware that one is slow here and the other is slow elsewhere, if they are
to be universal and cross platform then they should (imo) be optimized
for each platform, else why offer them at all? however..

> List is also slow on PHP and flash - so what ? Some containers are there
> for one target only, as far as I'm concerned they should be documented
> that way.

Now that is an interesting take on things, if they are tailored to
anything less than all platforms, then I'd argue that not only should
they be documented this way, but also that they shouldn't be in the std
cross platform API at all - and if they are, then they should be tested
to hell and back and optimized likewise.

> For me, the compiler brings type safety and a sane programming paradigm.
> Once you work on medium sized websites with 10K LOC javascript files,
> maintainability becomes a serious issue. The size of files should be
> pretty irrelevant, most browsers accept gzipped js files, haXe should
> market for large deployments where it's current feature set appeals,
> focusing on best practice development and fast turnaround (unlike GWT,
> which is dog slow).

Fully agree, tbh that's the main, possibly only, reason myself and a few
of the js focussed dev's I know use haxe(-js)

> Though I would agree that:
>
> - the Std library should be replaceable in its entirety, and be
> installable through haxelib. Anything else would stifle innovation in
> the community.

likewise, and if not this, then what?

Best,

Nathan

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

Re: javascript output optimization.

Andy Li
What I see from the discussion is, the different of pov towards Array/List.
One view is, they are different implementation of a collection, which should be chose by the developer, as if it is the developer's responsibility to choose between using Array or Hash or BST.
Another view is, there should be one universal collection class, and compiled down to an optimized implementation of the target platform, as if haXe code itself should compiled to optimized platform code.

Actually there is no conflict between the 2 views. Every data structure is provided. A universal collection class is also provided, that is FastList. So the platform-specific optimization should go to FastList but not Array/List.
And it is also discussed in the past, that's how haXe grows: First, provide wrapper to native platform API, then, build common API on top of them.

My own question is, after using haXe for a long time, I still don't see a valid use case of List. Are there really cases that List is faster than Array? Even there is, why not use FastList instead? Since there is no native implementation of List in any haXe-targeted platform (am i correct?), List is kind of redundant...

Best regards,
Andy

On Tue, Nov 30, 2010 at 7:46 AM, Nathan <[hidden email]> wrote:
Hi Niel,

Wise words, it's a good job you were told/asked to chip in :)

inline from here..


Niel Drummond wrote:
 I've been told to weigh into the discussion, though I must admit the
arguments are not that new.

That the haXe std containers have diverging performance on different
platforms is known , comparing List with Array on haXe-js is just silly.

Have to disagree, they're both in the root of std and core haxe API classes so equally valid to use, haxe developers shouldn't have to be aware that one is slow here and the other is slow elsewhere, if they are to be universal and cross platform then they should (imo) be optimized for each platform, else why offer them at all? however..


List is also slow on PHP and flash - so what ? Some containers are there
for one target only, as far as I'm concerned they should be documented
that way.

Now that is an interesting take on things, if they are tailored to anything less than all platforms, then I'd argue that not only should they be documented this way, but also that they shouldn't be in the std cross platform API at all - and if they are, then they should be tested to hell and back and optimized likewise.


For me, the compiler brings type safety and a sane programming paradigm.
Once you work on medium sized websites with 10K LOC javascript files,
maintainability becomes a serious issue. The size of files should be
pretty irrelevant, most browsers accept gzipped js files, haXe should
market for large deployments where it's current feature set appeals,
focusing on best practice development and fast turnaround (unlike GWT,
which is dog slow).

Fully agree, tbh that's the main, possibly only, reason myself and a few of the js focussed dev's I know use haxe(-js)


Though I would agree that:

- the Std library should be replaceable in its entirety, and be
installable through haxelib. Anything else would stifle innovation in
the community.

likewise, and if not this, then what?

Best,

Nathan


--
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.

Justin Donaldson-3
Hi Andy,

Here's an overview of the different iterables in haXe that I put together some time ago:

http://haxe.org/com/libs/listtools/which_iterable_type_should_i_use_

The real problem is the situation with actionscript (and to a lesser extent php).  In most other platforms, Arrays are a solid default.  With certain javascript vm's, Arrays are blindingly fast for small collections, but slow down for larger sizes... perhaps becoming slower than lists at some point on certain platforms.

Lists will be faster for inserts (into the middle of the list), but this functionality is not exposed through base haXe apis.  Lists are also the base type for safe functional transformations of collections... which are becoming increasingly popular.

In addition, other people here dislike iterables in general, and are looking at different methods of stepping through lists and other collections. 

It would be nice to have some sort of "iteration/enumeration shoot-out" for haXe.  It would be a collection of speed tests on various iterables that could be downloaded and run (via javascript/swf in the browser, or compiled and run on the user's machine).  The results would be human readable, but also could be uploaded back to a server that would analyze and aggregate times and the user's platform specific details for the tests.  I think there would be a lot of interesting details there, especially for tests that could be run on the new mobile devices.

Best,
-Justin

On Mon, Nov 29, 2010 at 6:12 PM, Andy Li <[hidden email]> wrote:
What I see from the discussion is, the different of pov towards Array/List.
One view is, they are different implementation of a collection, which should be chose by the developer, as if it is the developer's responsibility to choose between using Array or Hash or BST.
Another view is, there should be one universal collection class, and compiled down to an optimized implementation of the target platform, as if haXe code itself should compiled to optimized platform code.

Actually there is no conflict between the 2 views. Every data structure is provided. A universal collection class is also provided, that is FastList. So the platform-specific optimization should go to FastList but not Array/List.
And it is also discussed in the past, that's how haXe grows: First, provide wrapper to native platform API, then, build common API on top of them.

My own question is, after using haXe for a long time, I still don't see a valid use case of List. Are there really cases that List is faster than Array? Even there is, why not use FastList instead? Since there is no native implementation of List in any haXe-targeted platform (am i correct?), List is kind of redundant...

Best regards,
Andy

On Tue, Nov 30, 2010 at 7:46 AM, Nathan <[hidden email]> wrote:
Hi Niel,

Wise words, it's a good job you were told/asked to chip in :)

inline from here..


Niel Drummond wrote:
 I've been told to weigh into the discussion, though I must admit the
arguments are not that new.

That the haXe std containers have diverging performance on different
platforms is known , comparing List with Array on haXe-js is just silly.

Have to disagree, they're both in the root of std and core haxe API classes so equally valid to use, haxe developers shouldn't have to be aware that one is slow here and the other is slow elsewhere, if they are to be universal and cross platform then they should (imo) be optimized for each platform, else why offer them at all? however..


List is also slow on PHP and flash - so what ? Some containers are there
for one target only, as far as I'm concerned they should be documented
that way.

Now that is an interesting take on things, if they are tailored to anything less than all platforms, then I'd argue that not only should they be documented this way, but also that they shouldn't be in the std cross platform API at all - and if they are, then they should be tested to hell and back and optimized likewise.


For me, the compiler brings type safety and a sane programming paradigm.
Once you work on medium sized websites with 10K LOC javascript files,
maintainability becomes a serious issue. The size of files should be
pretty irrelevant, most browsers accept gzipped js files, haXe should
market for large deployments where it's current feature set appeals,
focusing on best practice development and fast turnaround (unlike GWT,
which is dog slow).

Fully agree, tbh that's the main, possibly only, reason myself and a few of the js focussed dev's I know use haxe(-js)


Though I would agree that:

- the Std library should be replaceable in its entirety, and be
installable through haxelib. Anything else would stifle innovation in
the community.

likewise, and if not this, then what?

Best,

Nathan


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


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



--
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: overriding getters and setters?

David Peek
Hi all,

Just wondering if anything ever came of this discussion RE overriding getters/setters from AVM2 classes. I vaguely remember reading a solution somewhere, but have Googled to no avail.

Here's the thread for reference:
http://haxe.1354130.n2.nabble.com/overriding-getters-and-setters-td4706472.html

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

Overriding getters and setters?

David Peek
Hi all,

Just wondering if anything ever came of this discussion RE overriding getters/setters from AVM2 classes. I vaguely remember reading a solution somewhere, but have Googled to no avail.

Here's the thread for reference:
http://haxe.1354130.n2.nabble.com/overriding-getters-and-setters-td4706472.html

Cheers,
David

PS sorry for posting to wrong thread, I'm a list noob :(

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

Re: javascript output optimization.

Niel Drummond-3
In reply to this post by Justin Donaldson-3
On 11/30/10 06:46, Justin Donaldson wrote:

That the haXe std containers have diverging performance on different
platforms is known , comparing List with Array on haXe-js is just silly.

Have to disagree, they're both in the root of std and core haxe API classes so equally valid to use, haxe developers shouldn't have to be aware that one is slow here and the other is slow elsewhere, if they are to be universal and cross platform then they should (imo) be optimized for each platform, else why offer them at all? however..


I doubt you can optimise each container to run equally fast on each target, just as unlikely is having a generic container with an acceptable level of features working on each target. That is an unfortunate consequence of having multiple targets and serialization between them.

Whether all that cross-platform nonsense is worth it... good question, but for 80-90% of use-cases, probably it isn't. I don't need to entertain the idea that developing on the entire haXe stack is not a realistic option for most companies.


Though I would agree that:

- the Std library should be replaceable in its entirety, and be
installable through haxelib. Anything else would stifle innovation in
the community.

likewise, and if not this, then what?

TBH, haXe-js will not get big and famous for macros, nor syntax sugar for monads, nor super fast and flexible containers, desirable how they may be for language enthusiasts. On the javascript target at least, in no order of importance and with complete disregard to feasibility, we should strive for:

- no global namespace clobbering
- output that conforms with external tools like google's closure and jslint
- output that does not reference VM dependent global interfaces (like Document and Window)
- a hosted debugging environment

These are unfortunately features that other compilers have, are useful, and compete directly with haXe's main audience. Solving these issues (or even pretending to care about it) would portray haXe-js as a viable alternative.

- Niel


Best,

Nathan


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


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




--
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.

sledorze
In reply to this post by Justin Donaldson-3

Different containers have different properties, I see as nonsense to compare Array and List BUT for a subset of their shared functionnalities.
Semantic and implementation are two different beasts, if I need an immutable datastructure and then exchange it for an array on a specific plateform, serious problems could start to happened here..


For the sake of the discussion; let's fledge a language enthousiast solution (eh.. possibility):
 
Algorithms would be paramatrize to abstract over the containers they manipulate:
These abstractions would represent the set of functions accessibles on those parameters: some of them would be 'Traversable' 'RandomIndexable' etc.. (i.e. Scala makes an overault of its collection library which is worth a look - however not in the dimension we're interested in here).

Then to use the algorithm, one could invoke the creation of a conforming container (specialized at compile time for the right plateform) or use an existing one with the right abstractions.
As haXe does not support variance, how to expose this? create interfaces? its heavy weight and cost much..
Create type classes and inline them by code specialization? we far from this..
etc..
etc..
Endless possibilities with more and more complex details.. 
.. there's a reason why this situation is happening.

So on the road of compiler tricks and super engineered solution, I see here a failure in the above proposition.

Has anyone a simpler proposition to the genericity/multi platform issue at the language/library level?
Feel free to propose it.

Perhaps it is just not realistic to abstract so much over the plateform, I think we're doing research here.
We have to propose, to realize if its possible or not, in other words to know..




On Tue, Nov 30, 2010 at 6:48 AM, Justin Donaldson-3 [via Haxe] <[hidden email]> wrote:
Hi Andy,

Here's an overview of the different iterables in haXe that I put together some time ago:

http://haxe.org/com/libs/listtools/which_iterable_type_should_i_use_

The real problem is the situation with actionscript (and to a lesser extent php).  In most other platforms, Arrays are a solid default.  With certain javascript vm's, Arrays are blindingly fast for small collections, but slow down for larger sizes... perhaps becoming slower than lists at some point on certain platforms.

Lists will be faster for inserts (into the middle of the list), but this functionality is not exposed through base haXe apis.  Lists are also the base type for safe functional transformations of collections... which are becoming increasingly popular.

In addition, other people here dislike iterables in general, and are looking at different methods of stepping through lists and other collections. 

It would be nice to have some sort of "iteration/enumeration shoot-out" for haXe.  It would be a collection of speed tests on various iterables that could be downloaded and run (via javascript/swf in the browser, or compiled and run on the user's machine).  The results would be human readable, but also could be uploaded back to a server that would analyze and aggregate times and the user's platform specific details for the tests.  I think there would be a lot of interesting details there, especially for tests that could be run on the new mobile devices.

Best,
-Justin


On Mon, Nov 29, 2010 at 6:12 PM, Andy Li <[hidden email]> wrote:
What I see from the discussion is, the different of pov towards Array/List.
One view is, they are different implementation of a collection, which should be chose by the developer, as if it is the developer's responsibility to choose between using Array or Hash or BST.
Another view is, there should be one universal collection class, and compiled down to an optimized implementation of the target platform, as if haXe code itself should compiled to optimized platform code.

Actually there is no conflict between the 2 views. Every data structure is provided. A universal collection class is also provided, that is FastList. So the platform-specific optimization should go to FastList but not Array/List.
And it is also discussed in the past, that's how haXe grows: First, provide wrapper to native platform API, then, build common API on top of them.

My own question is, after using haXe for a long time, I still don't see a valid use case of List. Are there really cases that List is faster than Array? Even there is, why not use FastList instead? Since there is no native implementation of List in any haXe-targeted platform (am i correct?), List is kind of redundant...

Best regards,
Andy

On Tue, Nov 30, 2010 at 7:46 AM, Nathan <[hidden email]> wrote:
Hi Niel,

Wise words, it's a good job you were told/asked to chip in :)

inline from here..


Niel Drummond wrote:
 I've been told to weigh into the discussion, though I must admit the
arguments are not that new.

That the haXe std containers have diverging performance on different
platforms is known , comparing List with Array on haXe-js is just silly.

Have to disagree, they're both in the root of std and core haxe API classes so equally valid to use, haxe developers shouldn't have to be aware that one is slow here and the other is slow elsewhere, if they are to be universal and cross platform then they should (imo) be optimized for each platform, else why offer them at all? however..


List is also slow on PHP and flash - so what ? Some containers are there
for one target only, as far as I'm concerned they should be documented
that way.

Now that is an interesting take on things, if they are tailored to anything less than all platforms, then I'd argue that not only should they be documented this way, but also that they shouldn't be in the std cross platform API at all - and if they are, then they should be tested to hell and back and optimized likewise.


For me, the compiler brings type safety and a sane programming paradigm.
Once you work on medium sized websites with 10K LOC javascript files,
maintainability becomes a serious issue. The size of files should be
pretty irrelevant, most browsers accept gzipped js files, haXe should
market for large deployments where it's current feature set appeals,
focusing on best practice development and fast turnaround (unlike GWT,
which is dog slow).

Fully agree, tbh that's the main, possibly only, reason myself and a few of the js focussed dev's I know use haxe(-js)


Though I would agree that:

- the Std library should be replaceable in its entirety, and be
installable through haxelib. Anything else would stifle innovation in
the community.

likewise, and if not this, then what?

Best,

Nathan


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


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



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



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


View message @ http://haxe.1354130.n2.nabble.com/javascript-output-optimization-tp5780561p5787115.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: overriding getters and setters?

go2ghana
In reply to this post by David Peek
Am 30.11.2010 06:51, schrieb David Peek:
> Hi all,
>
> Just wondering if anything ever came of this discussion RE overriding getters/setters from AVM2 classes. I vaguely remember reading a solution somewhere, but have Googled to no avail.
>
> Here's the thread for reference:
> http://haxe.1354130.n2.nabble.com/overriding-getters-and-setters-td4706472.html
>
> Cheers,
> David
Hi,
AFAIK no built in support until now but
adnez7 posted a solution with an external (neko) NamespaceInjector - see
http://haxer.be/zips/namespace-injector.zip

Cordially,
Axel

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

Re: overriding getters and setters?

Jan_Flanders
>
> Hi,
> AFAIK no built in support until now but
> adnez7 posted a solution with an external (neko) NamespaceInjector - see
> http://haxer.be/zips/namespace-injector.zip
>
> Cordially,
> Axel

It only handles namespaces which are completely different from getters
and setters.
I have tried to come up with a solution for this myself several times
but it's practically impossible to do, let alone maintain.
The main problem is getting passed the haXe compiler. First of all
haXe does not recognise the 'set' or 'get' keyword. It will compile
every method/function as trait kind 0x01 while a setter or getter
would be trait kind 0x02 or 0x03.
The haXe compiler and the verifier of the AVM in the flash player will
check if you are overriding a method (or getter or setter) with one
that has the exact same defintion as the original. (same arguments,
same return value). But in haXe a setter needs to have to same return
value as the getter, while for the AVM a setter MUST always have void
as return value. These two are incompatible.
Anyway you try, the compiler will not let you even compile. If you
leave out the 'override' keyword it complains you're overriding
without the 'override' keyword. Once you add that it will complain
that the definitions are not compatible because your return value is
not 'Void'. If you change it to Void, it will complain that setters
need to have the same return value as the getter...
Some will say to use composition instead but this is not always
possible. In those situations I write the 'incompatible' part in AS3
and use/inject that swf with -swf-lib.

Jan

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

Re: Overriding getters and setters?

Nicolas Cannasse
In reply to this post by David Peek
Le 30/11/2010 07:04, David Peek a écrit :
> Hi all,
>
> Just wondering if anything ever came of this discussion RE overriding
> getters/setters from AVM2 classes. I vaguely remember reading a solution
> somewhere, but have Googled to no avail.
>
> Here's the thread for reference:
> http://haxe.1354130.n2.nabble.com/overriding-getters-and-setters-td4706472.html

I just commited a hack/patch on SVN that enables the following :

class Foo extends Sprite {
        @:getter(width) function bar() {
                return 55;
        }
}

Please note that this will _replace_ the "bar" method, so DO NOT CALL it
directly.

PS : there's also @:setter as well

Nicolas

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

Re: javascript output optimization.

MarcWeber
In reply to this post by Niel Drummond-3
Excerpts from Niel Drummond's message of Tue Nov 30 08:36:12 +0100 2010:
> I doubt you can optimise each container to run equally fast on each
> target, just as unlikely is having a generic container with an
> acceptable level of features working on each target. That is an
> unfortunate consequence of having multiple targets and serialization
> between them.

...
In PHP lists are so damn slow than no operation on earth can make them
be faster than arrays - because building the list is more
expensive than any order of operations on lists could be.

(It may change if you have about 500.000 items or such - but that's not
the common case. Id say 1-10.000 or so is)

So if you want abstraction you have to abstract over list vs array.
Eg on PHP always use lists.

However this would mean retesting all of the existing code .. because
some behaviour has not been documented and will differ.

I'm talking about code like

var i = array.toIterator();
i.push(new element);

i.next().. // should the iterator contain the new element or not?

One could think about it : Not documented - so we don't have to care.

For those who don't know: I benchmarked different iterator
implementations: http://mawercer.de/~marc/bench
The code is on my github page.

The result was: Not using iterators is about 2-5 times faster than using
any iterator. Using Exception based iterators are about 2-x times
faster than any other iterator I benchmarked (Std, Stax, ..)

Exception: PHP (I think that's due to the lambda implementation - which
could be done differently on PHP 5.3) PHP was worse using the Exception
based iterators. Anyway: Even though arrays are the tool of choice when
targeting JS there are some cases Exception iterators can beat them.
Eg think about iterating the DOM and selecting all tags matching a
predicate. The array will win - unless you're interested in the first
match only. Then the "lazy" iterator can be faster - because it can stop
after having found one matching element.

You can find the final code here which I'll use in future projects:
https://github.com/MarcWeber/haxe-std-tiny
Performance is worse because I started using a function to abstract over
catching the "end of iterator Exception" - to reduce final code size.




I think its very important to understand the history of HaXe:
I read it somewhere that historically code was written for different
targets -and then maybe there was some effort to find generalized
interface.

That's why there is a list and an Array implementation - which both have
different methods names for appending elements - which makes it hard to
replace one implementation by a different one without using #ifdefs
Well - you could cast and use extern classes and rename methods.
So HaXe even would allow doing that.

Nevertheless I'd appreciate having one "list/array" like class which can
be used the array/list way which translates to list / array whatever is
fastest on a particular target. On PHP (and maybe JS) for moste use
cases this will be arrays.

However let's not forget that Stax introduces yet another list type: A
pure list: Each element is a "head-tail" connection. Thus you never have
to call a .clone() method to duplicate and modify a Stax list.
In turn adding an element at the tail will mean you have to recreate all
chain elements.

So what is most important about speed heavily depends on your use case.

John taught me that the speed of a simple list is not the biggest
problem in most cases.


When talking about speed maybe even this makes a difference:

function foo(){
  for i in 10.000
    hxroot.Class.method(i);
}

vs

function foo(){
  var method = hxroot.Class.method;
  for i in 10.000
    method(i);
}

Do current JS compilers optimise it? They are not allowed to - because
hxroot.Class.method(i) could change the value of hxroot.Class.method()
- so only HaXe knows that this is not the case.

In almost all cases only a fraction of the code takes most of time.
And maybe its worth optimizing that by writing native JS code.

Even Mootools devs did this by writing a new selector engine in JS
(without mootools fraework) for speed reasons.

As long as users are using ie7 performance will be bad - whatever you
do - because its more than 100 times slower than Chrome, Firefox or
Opera. (New IEs will have a new JS engine - so this is going to change).

So how much time do you want to spend on optimizing JS for which target?
(Some people are targeting JS engine v8)

Marc Weber

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

Re: javascript output optimization.

Nathan
Marc Weber wrote:
> So how much time do you want to spend on optimizing JS for which target?
> (Some people are targeting JS engine v8)

zero time, wiser to code to the standard interfaces and take the speed
gains as each engine makes them.

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

Re: javascript output optimization.

Andy Li
In reply to this post by MarcWeber
On Wed, Dec 1, 2010 at 12:38 AM, Marc Weber <[hidden email]> wrote:
Nevertheless I'd appreciate having one "list/array" like class which can
be used the array/list way which translates to list / array whatever is
fastest on a particular target. On PHP (and maybe JS) for moste use
cases this will be arrays.
 
Aren't FastList(or Justin's SugarList) is the answer?
It would be ideal to do either
  • drop List, and use FastList instead, or
  • replace List's implementation with SugarList's and drop FastList 
Or am I missing something?

Andy

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

Re: Overriding getters and setters?

David Peek
In reply to this post by Nicolas Cannasse
Hi Nicolas,

Wow, talk about response time! @getter seems to be working correctly, but not @setter. Looking at the changes you committed I thought (bear in mind I know exactly no OCAML) maybe the second MK3Getter should be MK3Setter instead?

genswf9.ml line 1768:
let rec lookup_kind = function
| [] -> f.cf_name, MK3Normal
| (":getter",[EConst (String f),_]) :: _ -> f, MK3Getter
| (":setter",[EConst (String f),_]) :: _ -> f, MK3Getter
| _ :: l -> lookup_kind l
in
let name, kind = lookup_kind f.cf_meta in

Or, you know, it could be something else entirely :)

Here's what I'm testing:

class Component extends flash.display.Sprite
{
public function new():Void
{
_width = 0;
}
private var _width:Float;
@:getter(width) function getter_width():Float
{
return _width;
}
@:setter(width) function setter_width(value:Float):Void
{
_width = value;
}
}

Thanks,
David

On 01/12/2010, at 1:25 AM, Nicolas Cannasse wrote:

Le 30/11/2010 07:04, David Peek a écrit :
Hi all,

Just wondering if anything ever came of this discussion RE overriding
getters/setters from AVM2 classes. I vaguely remember reading a solution
somewhere, but have Googled to no avail.

Here's the thread for reference:
http://haxe.1354130.n2.nabble.com/overriding-getters-and-setters-td4706472.html

I just commited a hack/patch on SVN that enables the following :

class Foo extends Sprite {
@:getter(width) function bar() {
return 55;
}
}

Please note that this will _replace_ the "bar" method, so DO NOT CALL it directly.

PS : there's also @:setter as well

Nicolas

--
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: Overriding getters and setters?

Nicolas Cannasse
Le 01/12/2010 05:30, David Peek a écrit :
> Hi Nicolas,
>
> Wow, talk about response time! @getter seems to be working correctly,
> but not @setter. Looking at the changes you committed I thought (bear in
> mind I know exactly /no/ OCAML) maybe the second MK3Getter should be
> MK3Setter instead?

Indeed ;)
Fixed on SVN
Please note that Flash9 setters should return Void if I remember correctly.

Nicolas

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