Interesting findings while profiling Eclipse
While profiling Eclipse on a Windows-System I came a round the File.toURI
. Every profiler session this method shows up under the top 10 hotspot method, while I never found that method on a MAC system — profiling the same application with the same workspace.
- I checked how many times this method was called while compiling my workspace and it was round about 100,000 times.
- I dig into the code:
toURI
was called to calculate a string which is used in a cache (as far as I understand the code)
Benchmark File.toURI
vs. File.getAbsoluteFile
With a simple test cases we can check the runtime for both variants on files and directories. For 100.000 calls I could not find a difference for getAbsoluteFile
on both systems. For toURI
it looks different: the Windows was 10 times slower.
toURI
produced an absolute path to a file with a schema prefix — in general all files in a workspace are on the same filesystem with the same schema prefix, therefore I suggest: Just replace toURI().toString()
to getAbsoluteFile().toString()
and the cache will still work as expected, but it will be much faster on Windows systems.
Conclusion
Or in other words: keep things simple and use only the information you really need: if you do not need the schema information of an URI, do not use a URI in favor of getAbsoluteFile()
.
Second: Java programs run on any platform and performance issues should be tracked down on that system they are reported for — ok, if you hit a n^2 algorithms this will likely operating system in dependent :).
Remarks
- The Windows system was a desktop machine with Windows 10 and SSD.
- The MAC was a MacBook with 10.12.3 and SSD.
- I did not publish run times, because the will differe on different system. A factor of 10 for the same base function on different systems with different underlaying file system is really interesting.
- I checked also the
toUri()
andtoAbsolutePath
from thePath
objects and get nearly the same results — no better performance on Windows.