My +1 in general. On Katharina's point, is it practical to just add a note to the HTML output, rather than looking for a code change, to the effect of "some small methods may have been inlined away," perhaps citing an option (-XsoycExtra, I see in the patch? Or maybe an option to -soyc, like -soyc[=default|detailed]?) to use for accurate-but-heavy-and-confusing output...
On Mon, Jun 29, 2009 at 4:48 PM, Katharina Probst <kpro...@google.com>wrote: > Hi Lex, > > all of what you say makes sense to me. I think SoyLite is a great idea and > we should go ahead with it. > > I do have one concern, however: as you mention below, some methods will > simply appear to disappear under SoyLite. For instance, in your first > example, Point.getX() will not appear to produce any output. I'm a bit > afraid that this will also cause confusion (and, similarly to partial > billing, some people may think the SOYC report is wrong). It is *less* > confusing than what's currently in trunk, but I am wondering whether there > could be a hybrid approach, where we record in a lightweight way, without > reverting back to the current expensive SOYC, where something gets inlined. > > It appears that partial billing is mainly due to inlining. Would it make > sense to annotate methods with inlining targets, so that the SOYC report > could show, for every method, all places where it was inlined into? While > this would incur an additional cost during compilation, it could clear up > some confusion in the final report. Is this too heavy-weight? > > For right now, I think SoyLite is a great idea. I would consider inlining > tracing a possible future enhancement. > > kathrin > > > > > > On Mon, Jun 29, 2009 at 12:20 PM, Lex Spoon <sp...@google.com> wrote: > >> >> On Sun, Jun 28, 2009 at 12:19 AM, John Tamplin<j...@google.com> wrote: >> > On Fri, Jun 26, 2009 at 3:20 PM, Lex Spoon <sp...@google.com> wrote: >> >> >> >> I've been trying to think of ways to speed up the -soyc option, and >> >> here is the result of one attempt. What do people think? >> >> >> >> The idea is to mimick some aspects of the speedy symbolMaps files. >> >> Instead of using the enhanced SourceInfo's to track links between >> >> before-optimization and after-optimization code, bill size information >> >> only to the program as it stands at the end of Java optimization. >> >> Additionally, be careful to avoid needing any massaging of the data >> >> in StoryRecorder; instead, make a single pass through all >> >> the size information. >> > >> > How much would it be skewed by JS-level optimizations? What about JSNI >> > code? >> >> The basic framework is the same in both cases. Output bytes get >> billed back to Java code. That's final output bytes, after all >> optimization is complete. Both would bill JSNI code to the associated >> Java native method. The difference is whether to map each byte to >> multiple methods, or to pick just one. >> >> Let me give some examples. Suppose Point is a class with a method >> getX() that is always inlined. Thus, Point.getX() is inlined away >> during Java optimization. Then suppose some method TextArea.getArea() >> calls Point.getX(). >> >> In trunk, Point.getX() is billed for every place it gets inlined, so >> it will show up in the size breakdown. TextArea.getArea(), meanwhile, >> will not be billed for all of its output bytes; the ones that it got >> by inlining Point.getX() will be partially billed back to >> Point.getX(). To contrast, with SoyLite, Point.getX() would not show >> up in the size output, and TextArea.getArea() would be billed slightly >> more. >> >> As another example, suppose Java method Integer.toString ends up >> compiling to JavaScript function toString_3. Also, suppose the >> compiler creates a static version Integer.toString$, which then >> compiles to function toString_4. In trunk, Integer.toString is given >> full blame for toString_3 and half blame for toString_4; >> Integer.toString$ is given half blame for toString_4. With SoyLite, >> Integer.toString is given full blame for toString_3, and >> Integer.toString$ is given full blame for toString_4. >> >> Does that clear things up better? If not, perhaps we should examine >> Showaces in more detail to find real examples of differences to look >> at. >> >> Lex >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
