FWIW, getString() requires an O(N) search to locate the relevant key. We usually work around this by using the SectionParser stuff, like CoreConfig. Those objects are cached inside of a HashMap, which reduces their lookup cost to be closer to O(1).

Fortunately this code only ones once per WorkingTreeIterator, but EGit might be creating many WTIs over the period of several minutes each time it needs to update decorations.

Although we probably still pay a higher cost to read the file than we do to look for the key in an O(N) search, so there might be a bigger savings from caching the file contents.

Its probably not worth creating a new SectionParser for this, but it might be OK to put this into the existing CoreConfig one.