[stringtemplate-interest] Raw speed!

VAUCHER Laurent 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.


Laurent.



More information about the stringtemplate-interest mailing list