Matt,
I created a Wave "Advanced GWT Compiler Optimizations" and invited
you to it. Anyone who sends me their sandbox ID, I will invite. I am
using it to collect non-trivial optimizations in an outline draft
where we can discuss them. As a first pass, I entered the idea of
Hybrid-SSA/Tree-SSA/Expression-only SSA with examples of how it can be
used to do better block level optimization.
-Ray
On Mon, Jun 15, 2009 at 7:09 PM, Matt Mastracci<matt...@mastracci.com> wrote:
>
> I do as well - I'm mmastrac.
>
> On 15-Jun-09, at 8:02 PM, Ray Cromwell wrote:
>
>>
>> I do, cromwellian is my id on the sandbox.
>>
>> -Ray
>>
>>
>> On Mon, Jun 15, 2009 at 6:14 PM, Bruce Johnson<br...@google.com>
>> wrote:
>>> I'm starting to make a bit o' progress on this. I'll send out a
>>> design doc
>>> "real soon now".
>>>
>>> BTW, anyone on the Contributors list here have Wave sandbox
>>> accounts? Sure
>>> would be easier to discuss this in a wave...
>>>
>>> On Mon, Jun 15, 2009 at 7:54 PM, Stefan Haustein
>>> <haust...@google.com>
>>> wrote:
>>>>
>>>> Ray,
>>>>
>>>> I think we can improve the class over time -- any reasonable
>>>> starting
>>>> point (even without iterators or with non-optimal iterators) would
>>>> help
>>>> significantly.
>>>>
>>>> Stefan
>>>>
>>>> On Sat, Jun 13, 2009 at 4:21 AM, Ray Cromwell
>>>> <cromwell...@gmail.com>
>>>> wrote:
>>>>>
>>>>> BTW, the last proposal is very unsafe with some form of escape
>>>>> analysis since it is unsafe to pass references to classes which
>>>>> reference local scope to other scopes. Another possibility is a
>>>>> form
>>>>> of 'destructuring' of Iterator classes by inlining them completely
>>>>> into local scope vs escape analysis and then forgoing separate
>>>>> construction.
>>>>>
>>>>> A simpler way to maintain for-each with JRE collections without
>>>>> creating objects is to change the way that for-each deals with
>>>>> Iterable<T> when T is a List.
>>>>>
>>>>> The compiler could change:
>>>>> for(T x : foo) { ... }
>>>>>
>>>>> where foo is a List<T>
>>>>>
>>>>> into
>>>>>
>>>>> for(int i=0; i<foo.size(); ++i) {
>>>>> T x = foo.get(i);
>>>>> }
>>>>>
>>>>> instead of calling foo.iterator() and using Iterator methods.
>>>>>
>>>>> -Ray
>>>>>
>>>>> On Fri, Jun 12, 2009 at 7:31 PM, Ray
>>>>> Cromwell<cromwell...@gmail.com>
>>>>> wrote:
>>>>>> I'm in the process of some final tweaks on GQuery, so I'll look
>>>>>> at how
>>>>>> much of my private JSArray class I can move over as a patch.
>>>>>>
>>>>>> One possibility for avoiding Iterator object creation without
>>>>>> using
>>>>>> flyweights is to introduce a new Iterator type which contains
>>>>>> methods
>>>>>> which are parameterized by the collection and which use my
>>>>>> Extension
>>>>>> Method/Category method JSO trick.
>>>>>>
>>>>>> public class FastIterator<T> extends JavaScriptObject {
>>>>>> protected FastIterator() {}
>>>>>> public <S, T extends List<S>> FastIterator<S> make(T<S> list) {
>>>>>> return (FastIterator<S>)(GWT.isScript() ? makeWeb() :
>>>>>> makeHosted());
>>>>>> }
>>>>>>
>>>>>> private final native FastIterator makeWeb() /*-{
>>>>>> return 0;
>>>>>> }-*/;
>>>>>>
>>>>>> private final native FastIterator makeHosted() /*-{
>>>>>> return [0];
>>>>>> }-*/;
>>>>>>
>>>>>> public final int value() {
>>>>>> return GWT.isScript() ? valueWeb() : valueHosted();
>>>>>> }
>>>>>>
>>>>>> public native int valueWeb() /*-{
>>>>>> return this;
>>>>>> }-*/;
>>>>>>
>>>>>> public native int valueHosted() /*-{
>>>>>> return this[0];
>>>>>> }-*/;
>>>>>>
>>>>>> public native hasNext(List<T> list) {
>>>>>> return value() < list.size();
>>>>>> }
>>>>>>
>>>>>> public native T next(List<T> list) {
>>>>>> return list.get(value()++); // unsure if using value() as
>>>>>> rvalue
>>>>>> will work here
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> then you should be able to write code like
>>>>>>
>>>>>> List<String> foo = getList();
>>>>>> FastIterator<String> iter = FastIterator.make(foo);
>>>>>>
>>>>>> while(iter.hasNext(foo)) {
>>>>>> String s = iter.next(foo);
>>>>>> }
>>>>>>
>>>>>> Why doesn't this create any additional objects? Because
>>>>>> 'iter'/FastIterator is actually a native JS number/scalar type,
>>>>>> and
>>>>>> what this is really doing is simulating the addition of
>>>>>> hasNext()/next() to the number's prototype.
>>>>>>
>>>>>> We could dispense with the need for an additional parameter if
>>>>>> GWT had
>>>>>> a magic method for allocating new local variables/symbols in the
>>>>>> local
>>>>>> scope. Imagine if writing
>>>>>>
>>>>>> Variable<T> x = GWT.createVariable(0);
>>>>>>
>>>>>> was a magic method that just generated a 'var x = 0'
>>>>>> declaration, only
>>>>>> it promised to always be inlined and do so in the caller's scope.
>>>>>> 'Variable' would be a magic class that never creates fields on the
>>>>>> actual object themselves and are pruned/removed at runtime.
>>>>>>
>>>>>> Then you could have FastIterator impersonate a reference to the
>>>>>> underlying List<T>, and rewrite hasNext()/next() as:
>>>>>>
>>>>>> VariableInt x = GWT.createVariableInt(0);
>>>>>> public boolean hasNext() {
>>>>>> return x.get() < this.size();
>>>>>> }
>>>>>>
>>>>>> public T next() {
>>>>>> return this.get(x.get()++); // or x.postIncrement()
>>>>>> }
>>>>>>
>>>>>> this would produce code that would create no additional objects as
>>>>>> well as maintain Iterator-like interface.
>>>>>>
>>>>>> -Ray
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 11, 2009 at 7:25 AM, Stefan Haustein<haust...@google.com
>>>>>> >
>>>>>> wrote:
>>>>>>> +1 Ray
>>>>>>> Could you contribute your implementation(s)?
>>>>>>>
>>>>>>> On Thu, Jun 11, 2009 at 12:51 PM, Joel Webber <j...@google.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> +1 Ray. Now here's the really tricky question. Is there any
>>>>>>>> way we
>>>>>>>> can
>>>>>>>> take advantage of Javascript's "for (x in y) { ... }" syntax
>>>>>>>> (and
>>>>>>>> should we,
>>>>>>>> given its spotty performance)? My intuition tells me that the
>>>>>>>> only
>>>>>>>> way we
>>>>>>>> could use it would be through a callback, because there's
>>>>>>>> nothing
>>>>>>>> like .NET
>>>>>>>> generators/yield in Javascript.
>>>>>>>> On Wed, Jun 10, 2009 at 7:26 PM, Ray Cromwell <cromwell...@gmail.com
>>>>>>>> >
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> My take on this is that there is many places where I'd like
>>>>>>>>> to avoid
>>>>>>>>> JRE collections, but the basic JsArray is too much of a
>>>>>>>>> downgrade. I
>>>>>>>>> don't mind changing it to <T> if it doesn't effect
>>>>>>>>> performance cause
>>>>>>>>> then I could subclass it, but as an example of the stuff I
>>>>>>>>> would
>>>>>>>>> like
>>>>>>>>> in a 'FastArrayList' that is not a collections derivative:
>>>>>>>>>
>>>>>>>>> 1) add() instead of just set(length(), item) (e.g. push)
>>>>>>>>> 2) addAll(anotherFastArrayList) (e.g. concat)
>>>>>>>>> 3) splice
>>>>>>>>> 4) toArray() (webmode is reinterpret cast op)
>>>>>>>>> 5) remove
>>>>>>>>> 6) shift/unshift (useful for queue when combined with pop)
>>>>>>>>>
>>>>>>>>> I use the following pattern all over GQuery to avoid JRE
>>>>>>>>> collections
>>>>>>>>> but preserve for-each
>>>>>>>>>
>>>>>>>>> for(Foo f : fooList.elements()) { ... }
>>>>>>>>>
>>>>>>>>> where fooList is my own JsArray<T> class, and elements()
>>>>>>>>> returns T[]
>>>>>>>>> via reinterpret cast in webmode.
>>>>>>>>>
>>>>>>>>> -Ray
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jun 11, 2009 at 2:43 AM, Lex Spoon<sp...@google.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Bah, mis-send. What I was typing was:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I though the point was to get rid of JRE collections?
>>>>>>>>>>> Anyway,
>>>>>>>>>>> the
>>>>>>>>>>> collection in question is used as a queue. I would hate to
>>>>>>>>>>> see
>>>>>>>>>>> its
>>>>>>>>>>> performance get worse when there'
>>>>>>>>>>
>>>>>>>>>> ...when there's a known, straightforward alternative, and when
>>>>>>>>>> that
>>>>>>>>>> alternative provides a class people have been wanting for
>>>>>>>>>> separate
>>>>>>>>>> purposes.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Lex
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Stefan Haustein
>>>>>>> Google UK Limited
>>>>>>>
>>>>>>> Registered Office: Belgrave House, 76 Buckingham Palace Road,
>>>>>>> London
>>>>>>> SW1W
>>>>>>> 9TQ; Registered in England Number: 3977902
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Stefan Haustein
>>>> Google UK Limited
>>>>
>>>> Registered Office: Belgrave House, 76 Buckingham Palace Road,
>>>> London SW1W
>>>> 9TQ; Registered in England Number: 3977902
>>>>
>>>
>>>
>>
>> >
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
