[stringtemplate-interest] Raw speed!
VAUCHER at fermat.fr
Thu Oct 13 23:45:56 PDT 2005
>> 1 ) the way properties are retrieved, for standard classes (isXXX,
>> getXXX or field access) is not recorded and has to be recomputed on
>> each access ;
>Yes, i have that on the to-do list :)
To be fair, that's where I read about it ;o)
>> I made a quick hack to fix the first point (thanks to/for the
>> open-sourceness of the lib) and observed a direct 25% decrease in
>> elasped time. Nice!
>Nice! So we should record a map (type,propertyName)->
>ReflectionObject so that if I ever see User object again
> and name property, it already has the reflection object
> necessary to get the field or whatever.
>Is that what you did?
Exactly. A simple map with string as keys (ClassName + "#" +
propertyName) and Methods or Fields as values.
I cannot decently propose to send you my current code, because it
is so ill-designed. But I can refactor it to make it prettier so
that it better fits in the global system. Where do you think
the map should live? In a StringTemplate? In the template group,
closer to the caching system?
>Would be easier to just generate java and compile it like JSP. :)
Probably, but that would require a compiler at runtime or a pre-
compilation phase and would get a bit too close to a full "engine":
not exactly what I long for.
On the other hand, we could probably adopt a progressive (incremental)
attitude regarding byte-code generation. A first step would be to
generate only property access code, to bypass reflection. That task
should not need very high skills to generate the byte-code. Further
steps would lead to full StringTemplate "compilation".
>> What do you think?
>I think you have good ideas! Vous etes tres malin! :)
You're too kind. I'm only trying to get some work done, and if
I can help make an already good tool a still better one, I
will be pleased.
More information about the stringtemplate-interest