On Sun, Jun 28, 2009 at 12:19 AM, John Tamplin<[email protected]> wrote: > On Fri, Jun 26, 2009 at 3:20 PM, Lex Spoon <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
