javascript output optimization.
Locked
1234
1234
 
|
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:
-- Stéphane Le Dorze Tel: +33 (0) 06 08 76 70 15 |
Re: javascript output optimization.
|
|
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 |
Re: javascript output optimization.
|
|
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 |
|
|
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:
-- Stéphane Le Dorze Tel: +33 (0) 06 08 76 70 15 |
Re: javascript output optimization.
|
|
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. -- haXe - an open source web programming language http://haxe.org |
|
|
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 |
|
|
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, -- haXe - an open source web programming language http://haxe.org |
Re: javascript output optimization.
|
|
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. -- blog: http://www.scwn.net aim: iujjd twitter: jjdonald -- haXe - an open source web programming language http://haxe.org |
Re: overriding getters and setters?
|
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 |
|
|
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 |
Re: javascript output optimization.
|
|
In reply to this post by Justin Donaldson-3
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.
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
-- haXe - an open source web programming language http://haxe.org |
|
|
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..
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, -- Stéphane Le Dorze Tel: +33 (0) 06 08 76 70 15 |
|
|
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 |
Re: overriding getters and setters?
|
>
> 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 |
Re: Overriding getters and setters?
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 Aren't FastList(or Justin's SugarList) is the answer? It would be ideal to do either
Or am I missing something? Andy -- haXe - an open source web programming language http://haxe.org |
Re: Overriding getters and setters?
|
|
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:
-- haXe - an open source web programming language http://haxe.org |
Re: Overriding getters and setters?
|
|
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 |
«
Return to Haxe
|
1 view|%1 views
| Free forum by Nabble | Edit this page |