[ 
https://issues.apache.org/jira/browse/WICKET-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712896#comment-17712896
 ] 

ASF GitHub Bot commented on WICKET-7047:
----------------------------------------

reiern70 commented on code in PR #579:
URL: https://github.com/apache/wicket/pull/579#discussion_r1168202846


##########
wicket-util/src/main/java/org/apache/wicket/util/string/Strings.java:
##########
@@ -1089,7 +1089,7 @@ public static CharSequence toMultilineMarkup(final 
CharSequence s)
                        return null;
                }
 
-               final AppendingStringBuffer buffer = new 
AppendingStringBuffer();
+               final AppendingStringBuffer buffer = new 
AppendingStringBuffer((int) (s.length() * 1.1));

Review Comment:
   > I don't think so. The additional 10% should be enough to accommodate 
markup and escaping overhead in most cases. And if it isn't enough, the buffer 
is resized once. This is _much_ better than resizing the buffer almost every 
time as it is now. Imho there is no need to configure or optimize this further.
   
   Yes... I after I wrote my comment I looked at soucre code and I realized the 
10% more should be enough. Maybe what we can have is a 
TenPercentMoreAppendingStringBuffer class?





> Improve initial buffer capacity for Strings.toMultilineMarkup
> -------------------------------------------------------------
>
>                 Key: WICKET-7047
>                 URL: https://issues.apache.org/jira/browse/WICKET-7047
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket-core
>    Affects Versions: 9.12.0
>            Reporter: Thomas Heigl
>            Assignee: Thomas Heigl
>            Priority: Major
>
> We currently create an AppendingStringBuffer with default capacity of 16 in 
> Strings#toMultilineMarkup. Since we know the size of the original string and 
> can take a guess at the additional length required for markup, it makes sense 
> to size this buffer appropriately.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to