Community
Participate
Working Groups
Currently there is one private constructor in EMF's URI class. It is both used by the static factory methods to create URI instances and the member methods returning another transformed URI (e.g. #appendFragment(String)). This private constructor always ends up calling String#intern() on the URI's scheme. This is unfortunately a quite expensive operation and can end up utilizing over 15% CPU time in an Xtext based application (Xtext uses URI#appendFragment(String) a lot for its lazy linking mechanism). As discussed on the newsgroup (see http://www.eclipse.org/forums/index.php/t/240884/) it would make sense to add a second private URI constructor which can be used by member methods like #appendFragment(String) where the URI scheme is already known to be interned (as the URI itself was created by a call to a static factory method which all still would be using the current constructor).
Created attachment 203652 [details] proposed patch Attached a proposed patch which adds a boolean "internScheme" parameter to the existing URI constructor.
I've now run some performance tests with a patched URI class as proposed. Although URI operations like #appendFragment(String) are now twice as fast, it turned out to be a bit of a red herring: I did the initial performance profiling (where String#intern() was reported as the top method with 15%) using YourKit, which apparently is unreliable when it comes to timing the execution of Java native methods. In other words, the proposed URI patch only has negligible effects on the overall performance of the profiled Xtext based application. So it would be fine with me to close this one as WONTFIX. Sorry about the fuzz.
Yes, I was very surprised to hear your numbers. I've done a lot of performance tuning, most recently for Mongo DB integration with Bryan Hunt, and at no point did URI methods ever appear near the top...
