Avoid duplicated IFileInfo fetches when creating resources #1598
Conversation
HannesWell
force-pushed
the
remove-duplicated-fileInfo-fetches
branch
from
15768cb
to
6bfdd8c
Compare
|
Isn't that intended extra check for case insensitive file systems? |
Where exactly? And how does it help to fetch the info of the same store twice? |
|
No, I just wondered that this extra check was behind extra "if" condition for case insensitive file systems. May be that is not a mistake but intention. I would check in git blame when it was added, for sure it is something Windows specific. |
| if (name != null && !store.getName().equals(name)) { | ||
| String msg = NLS.bind(Messages.resources_existsLocalDifferentCase, IPath.fromOSString(store.toString()).removeLastSegments(1).append(name).toOSString()); | ||
| String msg = NLS.bind(Messages.resources_existsLocalDifferentCase, | ||
| Path.of(store.toString()).resolveSibling(name)); | ||
| throw new ResourceException(IResourceStatus.CASE_VARIANT_EXISTS, getFullPath(), msg, null); |
There was a problem hiding this comment.
CASE_VARIANT_EXISTS makes only sense when name is tested against the actual name in the filesystem. This codepath is only taken if localInfo.exists(), so never in the performance critical case where where the directory is clean.
@jukzi I assume this didn't show up in your recent performance analysis of the resources handling so I assume it won't have a big impact, but avoiding subsequent duplicated file-fetches is probably still beneficial.