On Wed, Apr 8, 2009 at 2:51 AM, Freeland Abbott <[email protected]> wrote: > On Wed, Apr 8, 2009 at 2:38 AM, Lex Spoon <[email protected]> wrote: >> On Mon, Apr 6, 2009 at 8:48 PM, Freeland Abbott <[email protected]> >> wrote: >> > There's no special recursion I had to provoke; if you put logging in >> > instead >> > of my short circuit, I think DynaTable reconsiders java.lang.String >> > something like 23 times before reaching TIC shortcircuits. My patch >> > saved >> > almost 10% time for DynaTable, I think due to this earlier shortcircuit. >> > (Sorry, should have bragged on that in the first posting.) >> >> Wow, great! Hopefully we can make this same thing happen with the TIC >> shortcut. Probably a TIC-based short circuit could be inserted at the >> same place a visited shortcut is. > > My working copy still gets "I have visited information, but not TIC > information" at the shortcut point, apparently only for parameters of > parameterized type (that is, visited has an entry about "E extends > FooClass", but the matching tic.isDone() return false at that point). I > haven't yet had a chance to work through why that is, but I'm suspicious > whether the parameterization even gets its own TIC entry (no reason it > can't, right?) and if so, whether that is treated independently enough of > its parent class.
That sounds like an opportunity, but the patch as is makes me nervous. In general one parameterization might work even though another doesn't. For example, LinkedList<String> versus LinkedList<Socket>. Looking now, I see that the TIC short circuit is actually inside the loop in checkSubtypes. A pretty close change to what you put in would be to add a read-only check of the TIC outside the loop as well. It would need toquery for the existince of a TIC, and then only pay attention to it if it's either isDone() or isPendingInstantiable(). This would still have String being visited a lot of times; however, the more likely place we are losing time is for less trivial classes that actually have a lot of subclasses to consider. By the way, this whole thing can be simplified and sped up if we change from the recursive algorithm to an iterative one that uses a work list of TICs that need more work. After some point, we should jump in and do that 1-2 day refactor rather than patch on the recursive version. It also should also say "no" in some weird cases that we currently let through even though it won't work at run time. > Actually, what they get is "LeafClassOne is not default instantiable (it > must have a zero-argument constructor or no constructors at all) and has no > custom serializer. Do you have a report handy you could post? I'm especially interested in the case where the root type is abstract and all of its subclasses fail to be serializable. Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
