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