Optimize ODataPathExtensions.GetNavigationSource

[habbes]

Fix #1118

Replaces the use of ODataPathNavigationSourceHandler in ODataPath.GetNavigationSource extension method with a simpler reverse loop of the path.

With ODataPathNavigationSourceHandler

• a new instance of the handler is allocated
• all the segments of the path are visited
• a List<string> is created and populated with the string representation of each path segment. This list is used to generate a string representation of the path via a Path property. But this property is not needed to determine the navigation source (it's also not used by existing code).

The new implementation scans the path segments from the end and stops as soon as it finds the navigation source because only the last navigation source in the path matters.

The ODataPathNavigationSourceHandler is public so I kept it to avoid breaking changes.

Before

After

[gathogojr]

Is i > -1; better or more performant than i >= 0?

[habbes]

Good question. I'd assume it depends on the architecture. I may have naively assumed >= does "more" work than plan >, however, I think in this case architectures usually have special treatment for 0 and that may be more important here.

I have compared the assembly output of >= 0 and > -1 using sharplab.io and it appears that both of them get translated to the same assembly code which uses a greater than 0 comparison, rather than -1.

cmp dword ptr [ebp-8], 0 // comparison with 0
setge cl   // set if greater or equal

With that in mind, I'll change to >= 0 since it reads more naturally and it appears to be the compiler's preference.