Thanks for all your questions. Here are my answers. So, something like this has been used at least internally for quite a long > time -- what exactly did you have to change in StackTraceDeobfuscator? > Quite a few things, actually. I go into great detail about that, including diffs of some stack traces, in my paper: http://goo.gl/YGsrQ In short, my solution is prettier, more efficient, and more accurate than what you've been using.
I'm not sure that's going to be worth using in a performance-sensitive > application. Also, how much does this affect compilation time? Performance was critical to my application as well, and that's why I put in a lot of extra effort to make my solution almost 50% more efficient than my predecessor's work. I'm already using it in production on typeracer.com. You can visit my site and see that it's very fast. The impact on compilation time is negligible (less than 1 second per permutation). Do you plan to maintain that code if it is integrated into GWT or will it > be a one time contribution and other people have to wrap their head around > it again if your solution needs to be adjusted? > Yes, I will maintain the code regardless, even if it doesn't get integrated into GWT, because my app is already using it in production, and I consider it of high importance to my business. If my project gets funded, then I will work on integrating it into GWT and maintaining that code thereafter. Otherwise, if there's not enough interest from the community, I'm not sure I'll bother integrating it. Either way, my work is pretty self-contained and only touches a handful of existing classes: JsStackEmulator, StackTraceDeobfuscator, and StackTraceCreator. > I ask this because GWT will drop support for IE6/7 relatively soon and > probably by the end of 2014 drop support for IE8. Also Opera has switched > to Blink/V8 which makes the opera permutation obsolete in the near future. > So by the end of 2014 (GWT 3.x) Firefox, Safari, Chrome and Opera are > likely to support SourceMaps and in case of IE9+ stack trace emulation is > probably not needed. > In addition to fixing and optimizing stack emulation, my code makes lots of improvements to the SourceMaps-based approach as well. That said, right now, only one browser supports SourceMaps-based stack traces. Let me be clear: my project is not about just any one solution, like stack emulation or SourceMaps: it's to make perfect Java stack traces available in any browser that can run your GWT app. My code lays the foundation to make that happen with minimal future effort, even as browsers evolve. > So by the end of next year a bunch of your code can probably be deleted > and other code refactored/optimized to fit this situation. Have you thought > about that? I don't think any of my code will have to be deleted. I've introduced a selection property that selects whether the browser supports the SourceMaps-based stack traces or not, and introduces stack emulation only if needed. Otherwise, it uses the SourceMaps-optimized solution, which carries no overhead. What sort of approach does the current emulated stack implementation use, > as opposed to the suggested function enter/exit approach? Is there a > relative speed hit involved with it too? My approach to stack emulation is the same as before, just more accurate and more optimized. The cool thing is that in Chrome and any future browsers which provide both line and column numbers in Javascript stack traces, my code will give you perfect equivalent Java stack traces with absolutely no performance penalty (you can read about how it works in my paper: http://goo.gl/YGsrQ ) Because if so, bring on the new implementation ASAP :) I'm hoping to! Please consider making a donation and spread the word about my campaign: http://igg.me/at/gwt-stack-traces/x/3494291 :) Thanks guys. Any other questions? (I'm really excited to be having this discussion with all of you, after working on it in isolation for so long). - Alex Epshteyn On Wednesday, July 17, 2013 10:48:02 PM UTC-4, mark.e...@gmail.com wrote: > > If you use emulated stack traces (including line numbers) in current GWT >> your app size will roughly increase by 100%. So 45% is a lot better of what >> GWT gives you today. >> > > ... > > Really. I had not seen that mentioned anywhere. What sort of approach > does the current emulated stack implementation use, as opposed to the > suggested function enter/exit approach? Is there a relative speed hit > involved with it too? Because if so, bring on the new implementation ASAP > :) > > > On Wednesday, July 17, 2013 7:54:28 PM UTC-4, Jens wrote: >> >> >> I certainly applaud the obvious time, effort, and care that you've put >>> into these improvements, but "45% size and 22-44% execution speed overhead" >>> sounds like a rather painful penalty to pay. I'm not sure that's going to >>> be worth using in a performance-sensitive application. >> >> >> If you use emulated stack traces (including line numbers) in current GWT >> your app size will roughly increase by 100%. So 45% is a lot better of what >> GWT gives you today. >> >> >> >>> Also, how much does this affect compilation time? >>> >> >> This actually shouldn't matter for ordinary compilation. But it would be >> interesting to hear in case of SuperDevMode + non SourceMaps browser. >> >> >> -- J. >> > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
