-
Suggestion
-
Resolution: Not a bug
-
None
-
None
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
Suggested code improvement in Confluence source at com.atlassian.confluence.dashboard.actions.ConfigureRssFeedAction.createRssLink
The createRssLink method uses a StringBuffer without initiliazing the constructor to a value. This sets the internal char array of the StringBuffer to 16 chars by default. Each time you do an append the StringBuffer internally resizes at certain intervals. This uses additional CPU and memory for internal char array copies each time the appended amount exceeds the limits of the internal array. Though for a single execution of the method the performance impact may be negligible with a heavy loaded system with hundreds or thousands of users this could help scalability.
Additionally in the same method :
if (!publicFeed)
{ // Add authentication type parameter. Here we use BasicAuth to authenticate the rss feed. String authType = "&" + SecurityConfigFactory.getInstance().getAuthType() + "=" + SecurityConfig.BASIC_AUTH; rssString.append(authType); }Should be re-written to make better use of the StringBuffer append instead of concatenating Strings which in this case the authType concat operation creates 6 or 7 strings before being assigned to authType.
if (!publicFeed)
{ // Add authentication type parameter. Here we use BasicAuth to authenticate the rss feed. rssString.append('&'); rssString.append(SecurityConfigFactory.getInstance().getAuthType()); rssString.append('='); rssString.append(SecurityConfig.BASIC_AUTH); }Calling append is typically better performance than concatenating String objects.
- relates to
-
- Closed
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Micro-optimisations like this rarely show any noticeable benefit to application performance. For something as rarely called as createRssLink(), the cost of three or four array allocation/copies vanishes into insignificance compared to all the other stuff going on around it.
It is important to optimise judiciously - focusing effort on improving hotspots that the profiler shows are consuming the largest amounts of the application's runtime. Otherwise you can spend months fixing problems (like this) that are technically improvements, but that don't make any measurable difference in the performance of the application.
> Calling append is typically better performance than concatenating String objects.
The Java compiler optimises String concatenation into StringBuffer/Builder append operations behind the scenes.
http://fishbowl.pastiche.org/2002/09/04/the_stringbuffer_myth/
The only benefit you get from using StringBuffer directly is the ability to control the buffer's initial size, and the ability to pass the buffer into situations (like loops and other method) that the compiler can't optimise for you.