I think this is a great idea, especially because it can be offered side by side with the existing SOYC (that includes partial blame assignment). I agree with you, Lex, that explaining partial blame assignment has been a challenge. What I am still trying to understand is exactly how blame is assigned under SOYLite. I'm not familiar enough with the symbol maps, but what does happen when something gets inlined?
kathrin 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. > > This means that the size breakdown will no longer have fractional > sizes, and individual output bytes will no longer be fractionally > billed to different chunks of source code. The main question is, can > we live with that level of output? > > I have found in practice that people don't understand the fractional > billing. They ask why their methods have fractional sizes, and I > end up giving them a monolog about inlining until their eyes glaze > over. It seems that you need to understand the inlining effects > before you can understand what the current report gives you; > however, if you understand the inlining effects, it seems to me that > you can make good use of a report that doesn't use fractional billing. > > Additionally, it adds more pending work if SOYC continues to show both > before-optimization breakdowns and after-optimization dependency > information. To make a long story short, there are at least two > substantial work items related to this discrepency, and it would > remove that work if SOYC switched over to only reporting on the > program as it exists after Java optimization. > > Of course, we have to be happy with the new size breakdown. What do > people think--is the fractional billing important enough to pay the > extra compile time? Here are two example SOYC reports using each > method. The "lite" version drops fractional billing, so you'll see that > the sizes all end in ".0". > > http://www.lexspoon.org/soyc1821/trunk/SoycDashboard-index.html > http://www.lexspoon.org/soyc1821/lite/SoycDashboard-index.html > > In the lite version, please ignore all parts of a breakdown except the > package breakdown in the top-left pane. I wanted to share the idea > around before I finished implementing a lite version of the other > three panes. > > If the lite version looks fine, we will get some great timing > improvements. To show this, I tried compiling one-permutation > Showcase in four ways: both with and without -soyc, and both with and > without the patch. For each way of compiling, I compiled it four > times, but I discarded all the first results to try and reduce caching > effects. > > With the patch, the timings are as follows. The main number is the > average, with the individual timings in parentheses. > > regular compile: 36.5 (36.1, 35.9, 32.1) > with -soyc: 34.0 (33.9, 32.7, 35.5) > > By these numbers, using -soyc is faster than a regular build! I don't > know whether I introduce some overhead in a regular build, or if it's > just noise in the measurements. Either way, it looks good for the > speed of -soyc with the patch in. > > To compare, here are the numbers without the patch: > > regular compile: 34.0 (35.8, 34.0, 32.1) > with -soyc: 39.6 (40.2, 39.6, 39.0) > > > The regular compile time is exactly the same as the -soyc time after > the patch. As is already known, however, using -soyc without the > patch adds a lot of time, 16% by these measurements. Based on > PerfLogger, the StoryRecorder alone takes about 2.5-3 seconds, whereas > with the patch it takes less than half a second. > > Thoughts? A rough patch is attached, if anyone wants to play with it > themselves, but there's more to do if we want to go this way. > > Lex > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
