On Mon, Jan 5, 2009 at 5:59 AM, Byron Foster <[email protected]> wrote: > Here are some more performance numbers after Addressing the issues from the > last performance post (VELOCITY-662, VELOCITY-663), which reduced the > benchmark run time by about 20%. > > 9.8 ProxyVMContext get(String) > 6.7 PropertyExecutor execute(Object) > 6.3 EventHandlerUtil > referenceInsert(RuntimeServices,InternalContextAdapter,String,Object) > 4.8 ASTIdentifier execute(Object,InternalContextAdapter) > 4.6 ASTReference getVariableValue(Context,String) > 4.0 InternalContextAdapterImpl get(String) > 3.8 AbstractContext get(String) > 3.7 ASTText render(InternalContextAdapter,Writer) > 3.4 VelocimacroProxy > init(RuntimeServices,InternalContextAdapter,Node) > 3.3 InternalContextAdapterImpl icacheGet(Object) > > Top 10 offending methods. Some thoughts: It seems like the context.gets > are takiing some time. We could use a VelocityReference that would be a > delegate for String, but the hashCode value would be saved, so it wouldn't > have to recalculate on every get. ASTReference would then use > VelocityReference. > > ASTReference could register every reference in init() in an identity table. > When the put method was called on the VelocityContext it would first look > it up with the identity table (probably just a hash), if found it would use > the String from the identity table. HashMap get works much faster in this > case because equality can be determined from str1 == str2 instead of > str1.equals(str2), as it is done now.
Sounds to me like it would speed things up, but would it be enough to be worth the extra memory and complexity? I think it's worth considering, so i'd recommend measuring the change in memory usage and keeping code maintainability in mind too. If it turns out to not speed things up much, then it may not be worth it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
