See the padding Go inserts. Reorder in one click.
Inline annotations · visual byte map · pack score · cache lines · amd64/arm64/386
Install: ext install RhinoSoftware.go-memory-visualizer
Or: Marketplace · Open VSX · Website
type Sparse struct {
Active bool // 1B + 7B padding
ID uint64
Tag uint8 // 1B + 7B padding
Name string
}
// 40B · pack 65% · 14B wastedOpen the file → annotations appear → click Optimize Layout (save 8B · pack 65%):
Sparse 40B pack 65% pad 14B
0000 A.......BBBBBBBB
0010 C.......DDDDDDDD
0020 DDDDDDDD
legend: A=Active B=ID C=Tag D=Name .=padding
After reorder: 32B · pack 85% · saved 8 bytes. Same fields, less air.
- Spot padding without running
unsafe.Sizeofor reading the Go ABI by hand - Cut struct size 10–30% on hot types (API responses, events, DB models)
- Teach juniors (and yourself) how alignment actually works
- Paste the ASCII map into a PR when you want reviewers to see the waste
- Inline annotations showing memory details for each field
- Byte offsets so you know exactly where fields live
- Size calculations and alignment requirements
- Padding detection with visual warnings
- Color-coded warnings for excessive padding
- Cache line boundary detection (64-byte warnings)
- Hover tooltips with detailed breakdowns
- CodeLens buttons for one-click optimization
- Automatic field reordering by alignment and size
- Shows exact bytes saved before and after
- Preview before rewrite (current vs proposed order + pack score)
- Preserves your comments and struct tags
- Safe refactoring that doesn't break anything
- Works with nested and embedded structs
- Keeps grouped field lines intact when optimizing
- Byte-level colored grid for the struct under the cursor
- ASCII map you can paste into reviews or docs
- Pack score: how much of the struct is real data vs padding
- Export memory layout reports to JSON, Markdown, or CSV
- Detailed field-by-field analysis with offset, size, alignment, and padding information
- Architecture-specific reports for cross-platform analysis
- Perfect for documentation, code reviews, and performance audits
- Same-file type aliases and alias blocks resolve to their underlying Go types
- Slices use Go's three-word slice header size on each supported architecture
complex64uses 8 bytes with 4-byte alignment, matching Go's layout ruleserrorand any same-filetype X interface { ... }declarations are sized as 2-word interface values (16 bytes amd64/arm64, 8 bytes 386)- Anonymous inline struct fields (
Inner struct { ... }) are parsed and sized recursively, including multi-line declarations unsafe.Pointeris treated as a pointer-sized value
Supports amd64, arm64, and 386. Switch between them to see how pointer sizes affect layout.
- Open VS Code
- Press
Ctrl+P(Windows/Linux) orCmd+P(Mac) - Type:
ext install RhinoSoftware.go-memory-visualizer - Press Enter
Or visit the VS Code Marketplace
git clone https://github.com/1rhino2/go-memory-visualizer.git
cd go-memory-visualizer
npm install
npm run compile
code .
# Press F5 to launch Extension Development HostCreate or open any .go file with struct definitions:
type User struct {
Active bool // 1 byte + 7 padding
ID uint64 // 8 bytes
Name string // 16 bytes
Age uint8 // 1 byte + 7 padding
Balance float64 // 8 bytes
}The extension automatically shows:
// offset: 0 | size: 1 | align: 1 | padding: 7
Active bool
// offset: 8 | size: 8 | align: 8 | padding: 0
ID uint64
// Total: 48 bytes | Padding: 14 bytes (29% waste)
Click the CodeLens button above the struct:
Optimize struct - save 14 bytes (29% reduction)
type User struct {
ID uint64 // 8 bytes (no padding)
Balance float64 // 8 bytes (no padding)
Name string // 16 bytes (no padding)
Active bool // 1 byte (no padding)
Age uint8 // 1 byte + 6 final padding
}
// Total: 40 bytes | Padding: 6 bytes (15% waste)
// Saved 8 bytes (16.7% reduction)Access via Command Palette (Ctrl+Shift+P / Cmd+Shift+P):
| Command | Description |
|---|---|
Go: Show Memory Layout |
Display detailed memory breakdown for all structs |
Go: Show Visual Memory Map |
Byte-level colored map + ASCII for the struct at cursor |
Go: Optimize Struct Memory Layout |
Reorder fields in struct at cursor to minimize padding |
Go: Toggle Architecture |
Switch between amd64, arm64, and 386 |
Go: Export Memory Layout Report |
Export struct analysis to JSON/Markdown/CSV |
Go: Analyze Workspace Memory Layout |
Scan the workspace for padding and cache line issues |
Go: Compare Struct Layout Across Architectures |
Side-by-side amd64/arm64/386 layout for the struct at cursor |
Optimization is also available as a Quick Fix (Ctrl+. / Cmd+.) on any
struct that can be reordered for savings, and the status bar shows the total
bytes saveable in the current file at a glance. High-padding,
optimization-eligible, and cache-line-crossing structs are surfaced in the
Problems panel via diagnostics.
Customize via VS Code Settings (Ctrl+, / Cmd+,):
{
// Default architecture for memory calculations
"goMemoryVisualizer.defaultArchitecture": "amd64",
// Show inline annotations above struct fields
"goMemoryVisualizer.showInlineAnnotations": true,
// Highlight fields with excessive padding
"goMemoryVisualizer.highlightPadding": true,
// Minimum padding bytes to trigger warning (default: 8)
"goMemoryVisualizer.paddingWarningThreshold": 8,
// Show warnings for cache line boundary crossings
"goMemoryVisualizer.showCacheLineWarnings": true,
// Ask before rewriting field order (shows before/after preview)
"goMemoryVisualizer.confirmBeforeOptimize": true,
// Size time.Time, sync.Mutex, atomic.*, etc. from known layouts
"goMemoryVisualizer.useKnownStdlibTypes": true
}| Setting | Type | Default | Description |
|---|---|---|---|
defaultArchitecture |
string | "amd64" |
Architecture for calculations: amd64, arm64, or 386 |
showInlineAnnotations |
boolean | true |
Display memory info above each field |
highlightPadding |
boolean | true |
Highlight fields with padding waste |
paddingWarningThreshold |
number | 8 |
Min padding bytes to show warning |
showCacheLineWarnings |
boolean | true |
Warn about 64-byte cache line crossings |
confirmBeforeOptimize |
boolean | true |
Preview before rewriting field order |
useKnownStdlibTypes |
boolean | true |
Size time/sync/atomic/context from known layouts |
See examples/structs.go for demonstrations of:
- Well-optimized structs (minimal padding)
- Poorly-optimized structs (excessive padding)
- Common anti-patterns to avoid
- Best practices for field ordering
Before:
type APIResponse struct {
Success bool // 1 + 7 padding
Timestamp int64 // 8
Message string // 16
Code int32 // 4 + 4 padding
RequestID string // 16
}
// 56 bytes, 11 bytes wastedAfter:
type APIResponse struct {
Timestamp int64 // 8
Message string // 16
RequestID string // 16
Code int32 // 4
Success bool // 1 + 3 final padding
}
// 48 bytes, 3 bytes wastedImpact: 1M responses = 8 MB saved
The extension now automatically calculates memory layout for structs containing other custom structs:
type Point struct {
X float64 // 8 bytes
Y float64 // 8 bytes
}
type Rectangle struct {
TopLeft Point // 16 bytes (nested struct)
Width uint32 // 4 bytes
Height uint32 // 4 bytes
}
// Total: 24 bytesThe parser performs two-pass analysis:
- First pass: Register all struct definitions
- Second pass: Calculate layouts with nested struct sizes resolved
Embedded fields (promoted fields) are now properly detected and analyzed:
type Base struct {
ID uint64 // 8 bytes
CreatedAt int64 // 8 bytes
}
type User struct {
Base // embedded: 16 bytes
Name string // 16 bytes
Active bool // 1 byte + 7 padding
}
// Total: 40 bytesEmbedded pointers are also supported:
type Document struct {
*Metadata // embedded pointer: 8 bytes
Title string // 16 bytes
Published bool // 1 byte
}New command to export detailed struct analysis:
JSON Format: Machine-readable with full field details
{
"structs": [{
"name": "User",
"totalSize": 40,
"alignment": 8,
"totalPadding": 7,
"paddingPercentage": 17.5,
"fields": [...]
}],
"architecture": "amd64",
"exportedAt": "2025-11-23T12:00:00.000Z"
}Markdown Format: Human-readable documentation
## User
- **Total Size:** 40 bytes
- **Alignment:** 8 bytes
- **Total Padding:** 7 bytes (17.5%)
### Fields
| Field | Type | Offset | Size | Alignment | Padding After |
|-------|------|--------|------|-----------|---------------|
| ID | uint64 | 0 | 8 | 8 | 0 |CSV Format: Perfect for spreadsheets and data analysis
Struct,Field,Type,Offset,Size,Alignment,Padding After,Total Size,Total Padding,Padding Percentage,Architecture
User,ID,uint64,0,8,8,0,40,7,17.5,amd64Usage:
- Open a Go file with struct definitions
- Run command:
Go: Export Memory Layout Report - Choose format: JSON, Markdown, or CSV
- Save to desired location
Perfect for:
- Code reviews and documentation
- Performance audits
- Cross-architecture analysis
- Team collaboration
The extension follows Go's alignment rules:
-
Type Alignment: Each type has an alignment requirement:
bool,int8,uint8: 1 byteint16,uint16: 2 bytesint32,uint32,float32: 4 bytesint64,uint64,float64: 8 bytes- Pointers, strings, slices: 8 bytes (amd64/arm64), 4 bytes (386)
-
Field Placement: Each field starts at an offset aligned to its requirement
-
Padding Insertion: Go adds padding bytes to satisfy alignment
-
Final Padding: Struct size is rounded up to largest field alignment
1. Extract all fields from struct
2. Calculate current layout and total size
3. Sort fields:
- Primary: by alignment (descending)
- Secondary: by size (descending)
4. Recalculate layout with new ordering
5. Compare sizes and show savings
Run the comprehensive test suite:
npm testTest Coverage:
- 52 automated tests across parser, calculator, optimizer, diagnostics, arch compare, memory map, and known stdlib types
- CI runs compile, lint, and tests on Node 20 and 22
- DEMO.md: Interactive demonstrations and visual examples
- DEVELOPMENT.md: Developer guide and architecture
- CHANGELOG.md: Version history and release notes
Contributions welcome! Please:
- Fork the repository
- Create a feature branch (
git checkout -b feature/amazing-feature) - Commit changes (
git commit -m 'Add amazing feature') - Push to branch (
git push origin feature/amazing-feature) - Open a Pull Request
git clone https://github.com/1rhino2/go-memory-visualizer.git
cd go-memory-visualizer
npm install
npm run compile
npm test- VS Code: 1.85.0 or higher
- Go files:
.goextension in workspace - Node.js: 20.x or higher (for development)
None for v1.0.0. Previous limitations resolved:
Nested struct support✅ Added in v0.2.0Embedded struct handling✅ Added in v0.2.0Same-file type aliases✅ Added in v1.0.0- Union type support (planned)
See GitHub Issues for full list.
MIT License - see LICENSE file for details.
- Inspired by Go's memory layout documentation
- Built with VS Code Extension API
- Thanks to the Go community for feedback
- Issues: GitHub Issues
- Discussions: GitHub Discussions
- Contact: 1rhino2 on discord
- Nested struct support
- Embedded field handling
- Export layout reports
- Fixed export error handling
- Updated deprecated API usage
- Security fix: Patched path traversal vulnerability in export function
- Added path validation and normalization
- Implemented write verification and explicit file permissions
- Cache line visualization: Shows which 64-byte cache line each field occupies
- Cache line crossing detection: Warns when fields span multiple cache lines
- Workspace analyzer: New command scans all Go files for optimization opportunities
- Hot field detection for false sharing risks
- Security update: Fixed 18 security vulnerabilities (3 critical, 4 high, 10 medium, 1 low)
- XSS prevention with HTML/Markdown escaping
- Content Security Policy for webviews
- ReDoS protection with simplified regex patterns
- Resource limits for workspace analyzer
- See Security Advisory
- Visual memory map (byte grid + ASCII)
- Pack score in status bar, CodeLens, and exports
- Optimize preview with confirm-before-rewrite
- Known stdlib type sizes (time, sync, atomic, context)
- Union / sum-type visualization helpers
- Bitfield visualization
- Optional
unsafe.Sizeofcross-check via gopls
Made for the Go community
Website • GitHub • Marketplace • Docs
