http://gwt-code-reviews.appspot.com/1236801/diff/22001/6009 File dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java (right):
http://gwt-code-reviews.appspot.com/1236801/diff/22001/6009#newcode574 dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java:574: * structure of a type. Use a type's publicly accessible api to build a On 2011/01/04 22:25:03, jbrosenberg wrote:
Hmmm....I guess I thought the 2 were interchangeable here, since from
the
standpoint of a generator, what matters is what might have changed
based on what
can be returned by a type's public api.....I think I'm only using
public api
here to build the structure (except maybe some of the annotation
getters, which
by rights should be public api)....
I must be missing something. I thought that the TypeOracle provided private members. A quick poke in the source code and talk with jat seems to confirm that. For example, a generator could use an annotation on a private field to control behavior, right? Where do you think you're excluding non-public members?
On 2011/01/04 21:39:06, tobyr wrote: > I think you need to reword this, since you're building the signature
based on
> the type's structure, not the public API.
http://gwt-code-reviews.appspot.com/1236801/diff/22001/6009#newcode683 dev/core/src/com/google/gwt/dev/javac/typemodel/JClassType.java:683: lazyTypeStructureSignature = Util.computeStrongName(sb.toString().getBytes()); On 2011/01/04 22:25:03, jbrosenberg wrote:
I thought about using references to each object (instead of Strings),
but I
think that won't work in the case of persistent caching. To
individually go
through each structural component (with it's own sub-structure
implementation)
felt problematic, since the implementations can change for Methods,
Fields,
etc.....But yeah, I think we can optimize it to generate a byte[] or
byte[][]
array, without the intervening Strings....
I don't understand how implementation is related to this. Specific examples are things like access specifiers and other modifiers. No need to generate the string "private static transient volatile" when you can append a single 16-bit word that's already been read from the bytecode. JVMS signatures also tend to be more compact and are also directly available from the bytecode (no computation required).
I think the MD5 algorithm used by Util.computeStrongHash is pretty
efficient,
but I'm sure there are simpler, faster things we can use (or maybe
don't hash it
at all, just keep the full raw signature....trade-off being more
memory to store
and slower comparison times between signatures)...
The number of type signatures that get created will increase if this
is utilized
also for RPC, of course, so agreed, need to characterize the impact.
The alternative being what I had before, which was a simple last
modified date
stamp on the source file (which is problematic for freshly generated
source
files, or those living in jars, etc.).
Do you feel like the api here is perhaps good enough for now (we can
continue to
optimize later with a subsequent patch)?
I would feel best if you can get a measurement, prove it's a net win, then file an issue to make sure we take care of it.
On 2011/01/04 21:39:06, tobyr wrote: > This function looks expensive: > > 1) We're iterating over a lot of stuff. Probably can't be helped. > 2) We're using lots of functions that create lists of strings from
bits. Seems
> like we could just use the bits directly. > 3) The hash function seems potentially expensive. > > Can we measure it? How many times will it be called? (For example,
100us *
1000 > = 100ms, which is 2% of our total budget). We don't want to add new
work into
> the cost of refreshes, so we need to have a plan for dealing with
this if it
> turns out to be non-trivial.
http://gwt-code-reviews.appspot.com/1236801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
