overlay types not so zero-overhead

[Sebastián Gurin]

Hi all.

I'm playing with GWT overlay types for learning better ways of overlaying and working with them more agile. In particular I found that JSO setters methods that return 'this' for method chaining are a good way of defining an object state in a single Java statement, just like they are done in JavaScript. I written about this in http://cancerberonia.blogspot.com/2012/12/guidelines-for-writing-gwt-overlay-types.html

This setters methods look like this:

public native final MyJSO color(String val) /*-{
  this["color"]=val;
  return this;
}-*/;

So I can define an object in a single Java Statement like

MyJSO my1 = MyJSO.create().color("red").age(14);

I feel very confortable with that approach and using it on my GWT projects based on JSOs. But to my surprise (thanks to IRC user niloc132), these setters are not inlined in the GWT compiler JavaScript output. Please, read last part of my blog post "About Performance". For each setter a JavaScript function is defined and called: the JSNI code is not inlined. So this is not a zero overhead solution (as my libraries promise).

I tried different approachs for defining these setters, but with the same results in all cases. My question is, can I force the GWT compiler somehow to inline some of mine JSNI methods, perhaps with some annotation ? Do somebody have any suggestions for making setters returning 'this' to be inlined in javascript output instead of creating and calling javascript functions in javascript generated code ?

Regards and thanks in advance.

[Thomas Broyer]

On Wednesday, December 5, 2012 5:06:38 PM UTC+1, Sebastián Gurin wrote:

Hi all.

I'm playing with GWT overlay types for learning better ways of overlaying and working with them more agile. In particular I found that JSO setters methods that return 'this' for method chaining are a good way of defining an object state in a single Java statement, just like they are done in JavaScript. I written about this in http://cancerberonia.blogspot.com/2012/12/guidelines-for-writing-gwt-overlay-types.html

This setters methods look like this:

public native final MyJSO color(String val) /*-{
  this["color"]=val;
  return this;
}-*/;

So I can define an object in a single Java Statement like

MyJSO my1 = MyJSO.create().color("red").age(14);

I feel very confortable with that approach and using it on my GWT projects based on JSOs. But to my surprise (thanks to IRC user niloc132), these setters are not inlined in the GWT compiler JavaScript output. Please, read last part of my blog post "About Performance". For each setter a JavaScript function is defined and called: the JSNI code is not inlined. So this is not a zero overhead solution (as my libraries promise).

This last statement is misleading. JSOs do have zero-overhead, in the sense that they do exactly what you tell them to do: the generated code looks the same as the code you wrote, with no overhead due to having a Java class translated to JS as is the case for non-JSO classes. The fact that some methods are not inlined is not about overhead, it's about further optimization.

In other words, your code is equivalent to this JS code, no overhead:

function color(o, val) {

  o["color"] = val;

  return o;

}

function age(o, val) {

  o["age"] = val;

  return o;

}

var my1 = age(color({}, "red") 14);

(actually, the "color" and "age" strings would be moved to global variables, but that's another story)

 

I tried different approachs for defining these setters, but with the same results in all cases. My question is, can I force the GWT compiler somehow to inline some of mine JSNI methods, perhaps with some annotation ? Do somebody have any suggestions for making setters returning 'this' to be inlined in javascript output instead of creating and calling javascript functions in javascript generated code ?

Either don't return "this":

   MyJSO my1 = MyJSON.create();

   my1.setColor("red");

   my1.setAge(14);

or live with code that could be optimized further (and will probably be in a future version of GWT; maybe it's already the case with the Closure Compiler backend actually).

[Sebastián Gurin]

Thomas, thank you very much for your input. I think I will keep coding using method chaining and now at least I know they are not free in terms of code size and performance. Also I will test how this behaves introducing closure. Also I have made some little tests, the most interesting is using setters like this:

public native final JsFriendlyBeam age(int val) /*-{
  var v = this;
  v["age"]=val;
  return v;
}-*/;

In that case, the result of translating "chained" setters like

JsFriendlyBeam.create().color("turttlered2").age(14).head(JavaScriptObject.createObject());

is the following JavaScript output:

jsFriendlyBeam = (v = (v_1 = (v_0 = {} , v_0['color'] = 'turttlered2' , v_0) , v_1['age'] = 14 , v_1) , v['head'] = {} , v);


There the jsni is inlined like I want but at the cost of introducing new js variables v_# for each method call.

It do not occurs me how the setter chaining can be translated inline to javascript withtou introducing extra js functions of variables, so perhaps it is impossible. Thank you for the feedback.!