Community
Participate
Working Groups
3.3 M5 I'm currently trying to open up file buffers for URIs but now run into a wall because getting the URI for an IPath (URIUtil.toURI(IPath)) is very expensive.
Created attachment 58960 [details] Profiler data
NOTE: it is not just a compatibility issue: also clients that will use the new URI-based file buffer story will be much slower than now because they will call: bufferManager.getTextFileBuffer(myFile.getLocationURI()); which will be much more expensive (because of calling getLocationURI()) than bufferManager.getTextFileBuffer(myFile.getFullPath()); Hence both, the old story will be slower due to the migration layer in file buffers and the new API will also be slower because clients need to get the URI first.
This method is currently also heavily called by others in the system: FileSystemResourceManager or by the SyncFileWriter to fetch CVS info.
Is the profile output in instrumentation or sampling mode? What's the test case and VM?
*** Bug 174147 has been marked as a duplicate of this bug. ***
VM: 1.4.2_10 Used instrumentation (since the inv. count is there ;-) but same with sampling Test Case: path= full path of a valid resource in your test workspace manager= FileBuffers.getTextFileBufferManager(); for (int i= 0; i < 100000; i++) manager.getTextFileBuffer(path);
Can anything be done about this for 3.3? This method is called often and hence speeding it up would be a good improvement. I'm setting the target milestone as this is the performance pass milestone. Please remove it if you think nothing can be done for 3.3.
*** Bug 130736 has been marked as a duplicate of this bug. ***
I don't see any obvious performance improvements in these methods. We could cache recently created URIs, but I'm not sure if that will have much effect (outside of the micro-benchmark test described in comment #6). I did some instrumentation, and found that these methods are never called during typical resource manipulations (create, delete, copy, move, etc). The method is called only once each time an editor is opened. Thus, I don't think any performance work in this method will have any impact on user scenarios.
Please clarify if you think there is any noticeable improvement to be gained here.
>I'm not sure if that will have much effect (outside of the micro-benchmark test >described in comment #6). Why do you say "micro" benchmark? Because it often runs through that method? e.g. file buffer operations (e.g convert line delimiter) that can run over every single file in the workspace are a real life scenario. >The method is called >only once each time an editor is opened. Thus, I don't think any performance >work in this method will have any impact on user scenarios. This is not true. Take your dev workspace make a full build and see how many times URIUtil.toURI(String) gets called, e.g. via Resource.getLocationURI() which was reported in bug 174147 that got (correctly) marked as duplicate of this one. In addition see also bug 130736 which got reported by a different person and marked as dup of this one too. >Please clarify if you think there is any noticeable improvement to be gained >here. I never said that - it just popped up prominent when investigating and hence thought there *might* be overall improvement and I also said in my mail that I might be wrong and if you now say this code is OK and has no room for improvement then feel free to close.
Ok, I was just saying I didn't see anywhere it was being called often. Thanks for clarifying.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
