I haven't a clue myself, but the feeling I get is that the numerous changes and improvements from 1.4 to 1.5 are less focused on reducing the code size and more about improving code performance.
If code size is of high importance to you, I suggest you look at what (else) you can streamline within your own code base. /dave On Sep 5, 6:00 am, Kurt <[EMAIL PROTECTED]> wrote: > OK, so using OBF reveals that its much closer than I thought, but > still disappointing that the code size didn't go DOWN: > > 1.5 > 647,568 C760DB4C26233F65E2579723CA7BE050.cache.html > > 1.4 > 634,399 EFB925C5F054962BC7951D976730A34A.cache.html > > So 2% growth is not my issue. I was expecting/hoping for maybe a 20% > reduction since the linker should eliminate a bunch of unused/dead > code. I'm betting the new types for LinkedHashMap and > IdentityHashMap, etc. are being pulled in to cause some of the growth, > but who knows? > > On Sep 4, 7:01 pm, Folke <[EMAIL PROTECTED]> wrote: > > > On Sep 4, 3:42 pm, Kurt <[EMAIL PROTECTED]> wrote: > > > > [..] DETAILED [..] > > > Use OBF(USCATED) for a real comparison and PRETTY to see what's going > > on. > > > > I'm thinking that method inlining is the culprit, but want to get a > > > handle on it. > > > Can anyone tell me what to look at in generating the compilation > > > output to narrow down why the app is now 10% larger? > > > Yes, inlining is the "culprit", but there's also a lot of new code > > that adds more safety, like "long" emulation. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
