LT-22069: Speed up cross-project link navigation#969
Merged
Conversation
jasonleenaylor
approved these changes
Jun 25, 2026
jasonleenaylor
left a comment
jasonleenaylor
left a comment
Contributor
There was a problem hiding this comment.
@jasonleenaylor reviewed 1 file and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on mark-sil).
Clicking a cross-project hyperlink (e.g. FLExTrans links between two FLEx
projects) took several seconds to bring the target project to the fore,
with most of the time spent in .NET Remoting setup rather than the actual
jump.
Root cause: CreateRequestor connected to other FieldWorks processes via
"tcp://localhost:<port>/...". Resolving "localhost" tries IPv6 (::1) first
and waits ~2s for it to fail before falling back to IPv4. That stall is
paid once per first-contact to each other FieldWorks process's remoting
port. A link relay scans those ports three times during startup (the
update check, the single-process-mode check, and the actual handoff), so
the cost grows by ~2s for every additional FieldWorks instance running.
Fix: connect to the IPv4 loopback literal 127.0.0.1 instead of "localhost".
Measured with the German/Swedish FLExTrans sample projects (Debug x64),
varying the number of FieldWorks instances open. The per-instance ~2s cost
disappears and timing becomes flat:
Case 2 (target already open) - end-to-end click cost:
instances | before | after
2 | 4953ms | 1448ms
3 | 6967ms | 1426ms
4 | 9056ms | 1432ms
5 | 11269ms | 1405ms
Case 1 (target not yet open) - time to target window:
instances | before | after
1 | 5702ms | 3654ms
3 | 9637ms | 3765ms
5 | 14219ms | 3444ms
Before the fix the cost scaled linearly at ~2.1s per running instance;
after the fix it is flat regardless of how many instances are open. This
also speeds up normal multi-instance startup and cold cross-project opens,
which run the same probes. The remaining Case 1 time is project loading,
which this change does not affect.
The original report cited ~21s (Case 1) and ~10s (Case 2). We could not
confirm how many FieldWorks sessions the reporter had open at the time, so
this is a best guess - but it is the most likely explanation, since we
could only reproduce times of that magnitude with several (~4-5)
FieldWorks sessions running simultaneously.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
mark-sil
force-pushed
the
LT-22069-cross-project-link-perf
branch
from
d124f65 to
3f9187f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Clicking a cross-project hyperlink (e.g. FLExTrans links between two FLEx projects) took several seconds to bring the target project to the fore, with most of the time spent in .NET Remoting setup rather than the actual jump.
Root cause:
CreateRequestorconnected to other FieldWorks processes viatcp://localhost:<port>/.... Resolvinglocalhosttries IPv6 (::1) first and waits ~2s for it to fail before falling back to IPv4. That stall is paid once per first-contact to each other FieldWorks process's remoting port. A link relay scans those ports three times during startup (the update check, the single-process-mode check, and the actual handoff), so the cost grows by ~2s for every additional FieldWorks instance running.Fix: connect to the IPv4 loopback literal
127.0.0.1instead oflocalhost.Measurements
Measured with the German/Swedish FLExTrans sample projects (Debug x64), varying the number of FieldWorks instances open. Diagnosed with temporary cross-process timing markers (since removed); SLDR init (3 ms) and the jump itself (25 ms) were not the bottleneck.
Case 2 — target project already open (end-to-end click cost):
Case 1 — target project not yet open (time to target window):
Before the fix the cost scaled linearly at ~2.1 s per running instance; after the fix it is flat regardless of how many instances are open. This also speeds up normal multi-instance startup and cold cross-project opens, which run the same probes. The remaining Case 1 time is project loading, which this change does not affect.
Relationship to the reported times
The original report cited ~21 s (Case 1) and ~10 s (Case 2). We could not confirm how many FieldWorks sessions the reporter had open at the time, so this is our best guess — but it is the most likely explanation, because we were only able to reproduce times of that magnitude with several (~4–5) FieldWorks sessions running simultaneously. With the fix, those times become flat/low regardless of session count.
Testing
build.ps1 -SkipNative).silfw:link against the target project; confirmed the timings above and that target windows / jump behavior are unchanged.🤖 Generated with Claude Code
This change is