Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358175

Summary:

[common] add private URI constructor not calling String#intern()

Product:

[Modeling] EMF

Reporter:

Knut Wannheden <knut.wannheden>

Component:

Core

Assignee:

Ed Merks <Ed.Merks>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

enhancement

Priority:

CC:

sebastian.zarnekow

Version:

2.7.0

Target Milestone:

---

Hardware:

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
proposed patch	none

Description Knut Wannheden

2011-09-20 01:28:44 EDT

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).

Comment 1 Knut Wannheden

2011-09-20 04:42:16 EDT

Created attachment 203652 [details]
proposed patch

Attached a proposed patch which adds a boolean "internScheme" parameter to the existing URI constructor.

Comment 2 Knut Wannheden

2011-09-24 10:03:30 EDT

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.

Comment 3 Ed Merks

2011-09-24 11:11:10 EDT

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...