[SERVER-71911] shorten mongodbtoolchain revision/ codes (+stow suffixes?) Created: 06/Dec/22 Updated: 27/Oct/23 Resolved: 27/Oct/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Development Platform
|
| Participants: |
| Description |
|
Can we make the /opt/mongodbtoolchain/revisions/VERYLONGHEXNUMBER/ a shorter number? This number will appear millions of times and doesn't need to be anywhere near this strongly unique. This path is embedded into the dwarf debug info etc for every symbol in every library we build. It appears in symbolized backtraces many times. It's unnecessarily bulky and doesn't really give any useful information. |
| Comments |
| Comment by Billy Donahue [ 06/Dec/22 ] |
|
The full revision id is part of each symlink's body in the installed toolchain, so it's going to add more bulk to the path resolution of every single file accessed as part of every build. I don't know if it's significant but I could see it having an effect. I think the revision ID is also redundant with the 3-letter stow codes that predate its use in the toolchain builder. I might be wrong about this, but I believe they are both serving a similar purpose of indirection. So a kernel resolving these symlinks during a build is going to have an extra hop that can be eliminated. Like there's only ever one stow suffix per toolchain product: gcc-v2.hue In the olden days, when designing the v3 layout, I had these stows for the same reason we have revisions/ nowadays. We may not need both things. |