I'd be happy to take on this task. What is the work flow for
contributing? I don't have committing access so is a patch best? Also,
where do I do the work -- on a specific branch or the trunk?
Where I noticed small improvements can possibly be made with
StringBuilder are:
** com.nary.util.string for things
- replaceChars() - used by HtmlEditFormat() BIF via escapeHtml()
- hashCodeMD5()
** com.naryx.tagfusion.expression.function.listInsertAt
Looks like StringBuffer is used to adjust the position of the list via a
loop. An insert of a list of 9 elements, makes 21 calls to the SB --
all of which are synchronized. I have a feeling this would be a bit faster.
** com.naryx.tagfusion.expression.function.listDeleteAt
Similar use of listInsertAt() using the StringBuffer. A billion
synchronized calls going on that compound as the list size grows.
** com.naryx.tagfusion.expression.function.listChangeDelims
** com.naryx.tagfusion.expression.function.listQualify
** com.naryx.tagfusion.expression.function.listSetAt
A buffer is used to loop over and append. Again synchronized calls
compound with list size.
I'm also curious about com.nary.util.string.split(). It's comments say
it's been tuned for JDK 1.4 saying that direct code is faster than using
StringTokenizer. I'm wondering if this is the case now with 1.5 / 1.6?
Split() is used by a whole ton of list*() BIF in CFML -- I'm wondering
if split() is retuned if some performance can be gained.
Another place I'm looking at is com.nary.util.string.replaceString() use
of StringWriter which uses StringBuffer underneath. Based on what I've
read, you can pass in a *StringBuilder* into the constructor of
StringWriter to rid yourself of the synchronization penalty that
StringBuffer has. It would look something like:
StringBuilder sb = new StringBuilder( _Line.length() );
StringWriter writer = new StringWriter( sb );
int start = 0;
while ( ... ) {
code here using writer.write()
}
... yadda yadda ...
line = sb.string()
Another places for StringBuffer:
** com.naryx.tagfusion.expression.fucntion.reReplace
** com.naryx.tagfusion.expression.fucntion.expandPath
** com.naryx.tagfusion.expression.fucntion.numberFormat
What about the com.naryx.tagfusion.cfm.tag.cfParseTag -- that looks to
be a high traffic file and has a lot of StringBuffer stuff in it.
So, that's just my casual look at the code base for now. I was looking
at places for improvement for CFML tags, not general request behind the
scenes stuff. I know a lot of these look inconsequential, but based on
the small performance improvements we've been able to eek out in Mach-II
-- they help by adding up over time.
Best,
.Peter
Alan Williamson (aw1) said the following on 09/25/2009 07:34 AM:
> That will have been me in most cases -- as i come to them i have been
> replacing them.
>
> But as Vince notes, all the areas that are key to rendering a request,
> have already been done. Anything else, is not key to page-request times
> so no huge gain will be had by doing a simple-search-replace.
>
>
>
>
>> Also, it looks like
>> someone has gone through and already done some of this, since I found
>> 110 references to StringBuilder.
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Open BlueDragon Public Mailing List
http://groups.google.com/group/openbd?hl=en
official site @ http://www.openbluedragon.org/
!! save a network - trim replies before posting !!
-~----------~----~----~----~------~----~------~--~---
