Community
Participate
Working Groups
I20040204 I was tracing performance when opening an editor and saw that > 7% is spent in String.substring which is called by Path.computeSegments(String). The reason why computeSegments is called can be found in bug 51244 (note: JavaElement.toString ends up calling Path.computeSegments(String)).
Please note that when using builds > 20040206 you might not see this because J Core already improved the code (see bug 51249).
I think the decoration job was just reporting too much progress. Unless you have specific optimization recommendations for the computeSegments method, I don't see anything else we can do here (it is already fairly well tuned). It is inherently expensive because it is creating all of the String objects for each segment of the path.
Couldn't you setup a reader on the string and then build the array in one pass without calling substring and in addition inline the call to computeSegmentCount? I guess this might be faster.
The performance of this method is really tied to the number of object creations. This implementation creates n+1 objects, where n is the number of segments in the path. This is optimal, considering the internal representation of path as an array of strings. This representation was carefully chosen to avoid any object creations while iterating over a path (which is done on every resource tree lookup), at the expense of slightly more expensive creation time.
