Remove outdated performance analysis documents
- Deleted the `dungeon_editor_bottleneck_analysis.md`, `editor_performance_monitoring_setup.md`, `lazy_loading_optimization_summary.md`, and `overworld_optimization_status.md` files as they are no longer relevant to the current optimization strategies and performance monitoring efforts. - This cleanup helps streamline the documentation and focuses on the most up-to-date performance insights and optimization techniques.
This commit is contained in:
scawful
@@ -1,125 +0,0 @@
|
||||
# DungeonEditor Bottleneck Analysis
|
||||
|
||||
## 🚨 **Critical Performance Issue Identified**
|
||||
|
||||
### **Problem Summary**
|
||||
The **DungeonEditor::Load()** is taking **18,113ms (18.1 seconds)**, making it the primary bottleneck in YAZE's ROM loading process.
|
||||
|
||||
### **Performance Breakdown**
|
||||
|
||||
| Component | Time | Percentage |
|
||||
|-----------|------|------------|
|
||||
| **DungeonEditor::Load** | **18,113ms** | **97.3%** |
|
||||
| OverworldEditor::Load | 527ms | 2.8% |
|
||||
| All Other Editors | <6ms | <0.1% |
|
||||
| **Total Loading Time** | **18.6 seconds** | **100%** |
|
||||
|
||||
## 🔍 **Root Cause Analysis**
|
||||
|
||||
The DungeonEditor is **36x slower** than the entire overworld loading process, which suggests:
|
||||
|
||||
1. **Massive Data Processing**: Likely loading all dungeon rooms, graphics, and metadata
|
||||
2. **Inefficient Algorithms**: Possibly O(n²) or worse complexity
|
||||
3. **No Lazy Loading**: Loading everything upfront instead of on-demand
|
||||
4. **Memory-Intensive Operations**: Large data structures being processed
|
||||
|
||||
## 🎯 **Detailed Timing Added**
|
||||
|
||||
Added granular timing to identify the exact bottleneck:
|
||||
|
||||
```cpp
|
||||
// DungeonEditor::Load() now includes:
|
||||
{
|
||||
core::ScopedTimer rooms_timer("DungeonEditor::LoadAllRooms");
|
||||
RETURN_IF_ERROR(room_loader_.LoadAllRooms(rooms_));
|
||||
}
|
||||
|
||||
{
|
||||
core::ScopedTimer entrances_timer("DungeonEditor::LoadRoomEntrances");
|
||||
RETURN_IF_ERROR(room_loader_.LoadRoomEntrances(entrances_));
|
||||
}
|
||||
|
||||
{
|
||||
core::ScopedTimer palette_timer("DungeonEditor::LoadPalettes");
|
||||
// Palette loading operations
|
||||
}
|
||||
|
||||
{
|
||||
core::ScopedTimer usage_timer("DungeonEditor::CalculateUsageStats");
|
||||
usage_tracker_.CalculateUsageStats(rooms_);
|
||||
}
|
||||
|
||||
{
|
||||
core::ScopedTimer init_timer("DungeonEditor::InitializeSystem");
|
||||
// System initialization
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 **Expected Detailed Results**
|
||||
|
||||
The next performance run will show:
|
||||
|
||||
```
|
||||
DungeonEditor::LoadAllRooms 1 XXXXms XXXXms
|
||||
DungeonEditor::LoadRoomEntrances 1 XXXXms XXXXms
|
||||
DungeonEditor::LoadPalettes 1 XXXXms XXXXms
|
||||
DungeonEditor::CalculateUsageStats1 XXXXms XXXXms
|
||||
DungeonEditor::InitializeSystem 1 XXXXms XXXXms
|
||||
```
|
||||
|
||||
## 🚀 **Optimization Strategy**
|
||||
|
||||
### **Phase 1: Identify Specific Bottleneck**
|
||||
- Run performance test to see which operation takes the most time
|
||||
- Likely candidates: `LoadAllRooms` or `CalculateUsageStats`
|
||||
|
||||
### **Phase 2: Apply Targeted Optimizations**
|
||||
|
||||
#### **If LoadAllRooms is the bottleneck:**
|
||||
- Implement lazy loading for dungeon rooms
|
||||
- Only load rooms that are actually accessed
|
||||
- Use progressive loading for room graphics
|
||||
|
||||
#### **If CalculateUsageStats is the bottleneck:**
|
||||
- Defer usage calculation until needed
|
||||
- Cache usage statistics
|
||||
- Optimize the calculation algorithm
|
||||
|
||||
#### **If LoadRoomEntrances is the bottleneck:**
|
||||
- Load entrances on-demand
|
||||
- Cache entrance data
|
||||
- Optimize data structures
|
||||
|
||||
### **Phase 3: Advanced Optimizations**
|
||||
- **Parallel Processing**: Load rooms concurrently
|
||||
- **Memory Optimization**: Reduce memory allocations
|
||||
- **Caching**: Cache frequently accessed room data
|
||||
- **Progressive Loading**: Load rooms in background threads
|
||||
|
||||
## 🎯 **Expected Impact**
|
||||
|
||||
### **Current State**
|
||||
- **Total Loading Time**: 18.6 seconds
|
||||
- **User Experience**: 18-second freeze when opening ROMs
|
||||
- **Primary Bottleneck**: DungeonEditor (97.3% of loading time)
|
||||
|
||||
### **After Optimization (Target)**
|
||||
- **Total Loading Time**: <2 seconds (90%+ improvement)
|
||||
- **User Experience**: Near-instant ROM opening
|
||||
- **Bottleneck Eliminated**: DungeonEditor optimized to <1 second
|
||||
|
||||
## 📈 **Success Metrics**
|
||||
|
||||
- **DungeonEditor::Load**: <1000ms (down from 18,113ms)
|
||||
- **Total ROM Loading**: <2000ms (down from 18,600ms)
|
||||
- **User Perceived Performance**: Near-instant startup
|
||||
- **Memory Usage**: Reduced initial memory footprint
|
||||
|
||||
## 🔄 **Next Steps**
|
||||
|
||||
1. **Run Performance Test**: Load ROM and collect detailed timing
|
||||
2. **Identify Specific Bottleneck**: Find which operation takes 18+ seconds
|
||||
3. **Implement Optimization**: Apply targeted fix for the bottleneck
|
||||
4. **Measure Results**: Verify 90%+ improvement in loading time
|
||||
|
||||
The DungeonEditor optimization will be the final piece to make YAZE lightning-fast!
|
||||
@@ -1,109 +0,0 @@
|
||||
# Editor Performance Monitoring Setup
|
||||
|
||||
## Overview
|
||||
|
||||
Successfully implemented comprehensive performance monitoring across all YAZE editors to identify loading bottlenecks and optimize the entire application startup process.
|
||||
|
||||
## ✅ **Completed Tasks**
|
||||
|
||||
### 1. **Performance Timer Standardization**
|
||||
- Cleaned up and standardized all performance monitoring timers
|
||||
- Added consistent `core::ScopedTimer` usage across all editors
|
||||
- Integrated with the existing `core::PerformanceMonitor` system
|
||||
|
||||
### 2. **Editor Timing Implementation**
|
||||
Added performance timing to all 8 editor `Load()` methods:
|
||||
|
||||
| Editor | File | Status |
|
||||
|--------|------|--------|
|
||||
| **OverworldEditor** | `overworld/overworld_editor.cc` | ✅ Already had timing |
|
||||
| **DungeonEditor** | `dungeon/dungeon_editor.cc` | ✅ Added timing |
|
||||
| **ScreenEditor** | `graphics/screen_editor.cc` | ✅ Added timing |
|
||||
| **SpriteEditor** | `sprite/sprite_editor.cc` | ✅ Added timing |
|
||||
| **MessageEditor** | `message/message_editor.cc` | ✅ Added timing |
|
||||
| **MusicEditor** | `music/music_editor.cc` | ✅ Added timing |
|
||||
| **PaletteEditor** | `graphics/palette_editor.cc` | ✅ Added timing |
|
||||
| **SettingsEditor** | `system/settings_editor.cc` | ✅ Added timing |
|
||||
|
||||
### 3. **Implementation Details**
|
||||
|
||||
Each editor now includes:
|
||||
```cpp
|
||||
#include "app/core/performance_monitor.h"
|
||||
|
||||
absl::Status [EditorName]::Load() {
|
||||
core::ScopedTimer timer("[EditorName]::Load");
|
||||
|
||||
// ... existing loading logic ...
|
||||
|
||||
return absl::OkStatus();
|
||||
}
|
||||
```
|
||||
|
||||
## 🎯 **Expected Results**
|
||||
|
||||
When you run the application and load a ROM, you'll now see detailed timing for each editor:
|
||||
|
||||
```
|
||||
=== Performance Summary ===
|
||||
Operation Count Total (ms) Average (ms)
|
||||
------------------------------------------------------------------------
|
||||
OverworldEditor::Load 1 XXX XXX
|
||||
DungeonEditor::Load 1 XXX XXX
|
||||
ScreenEditor::Load 1 XXX XXX
|
||||
SpriteEditor::Load 1 XXX XXX
|
||||
MessageEditor::Load 1 XXX XXX
|
||||
MusicEditor::Load 1 XXX XXX
|
||||
PaletteEditor::Load 1 XXX XXX
|
||||
SettingsEditor::Load 1 XXX XXX
|
||||
LoadAllGraphicsData 1 XXX XXX
|
||||
------------------------------------------------------------------------
|
||||
```
|
||||
|
||||
## 🔍 **Bottleneck Identification Strategy**
|
||||
|
||||
### **Phase 1: Baseline Measurement**
|
||||
Run the application and collect performance data to identify:
|
||||
- Which editors are slowest to load
|
||||
- Total loading time breakdown
|
||||
- Memory usage patterns during loading
|
||||
|
||||
### **Phase 2: Targeted Optimization**
|
||||
Based on the results, focus optimization efforts on:
|
||||
- **Slowest Editors**: Apply lazy loading or deferred initialization
|
||||
- **Memory-Intensive Operations**: Implement progressive loading
|
||||
- **I/O Bound Operations**: Add caching or parallel processing
|
||||
|
||||
### **Phase 3: Advanced Optimizations**
|
||||
- **Parallel Editor Loading**: Load independent editors concurrently
|
||||
- **Predictive Loading**: Pre-load editors likely to be used
|
||||
- **Resource Pooling**: Share resources between editors
|
||||
|
||||
## 🚀 **Next Steps**
|
||||
|
||||
1. **Run Performance Test**: Load a ROM and collect the performance summary
|
||||
2. **Identify Bottlenecks**: Find the slowest editors (likely candidates: DungeonEditor, ScreenEditor)
|
||||
3. **Apply Optimizations**: Implement lazy loading for slow editors
|
||||
4. **Measure Improvements**: Compare before/after performance
|
||||
|
||||
## 📊 **Expected Findings**
|
||||
|
||||
Based on typical patterns, we expect to find:
|
||||
|
||||
- **OverworldEditor**: Already optimized (should be fast)
|
||||
- **DungeonEditor**: Likely slow (complex dungeon data loading)
|
||||
- **ScreenEditor**: Potentially slow (graphics processing)
|
||||
- **SpriteEditor**: Likely fast (minimal loading)
|
||||
- **MessageEditor**: Likely fast (text data only)
|
||||
- **MusicEditor**: Likely fast (minimal loading)
|
||||
- **PaletteEditor**: Likely fast (small palette data)
|
||||
- **SettingsEditor**: Likely fast (configuration only)
|
||||
|
||||
## 🎉 **Benefits**
|
||||
|
||||
- **Complete Visibility**: See exactly where time is spent during ROM loading
|
||||
- **Targeted Optimization**: Focus efforts on the real bottlenecks
|
||||
- **Measurable Progress**: Track improvements with concrete metrics
|
||||
- **User Experience**: Faster application startup and responsiveness
|
||||
|
||||
The performance monitoring system is now ready to identify and help optimize the remaining bottlenecks in YAZE's loading process!
|
||||
@@ -1,143 +0,0 @@
|
||||
# Lazy Loading Optimization Implementation Summary
|
||||
|
||||
## Overview
|
||||
|
||||
Successfully implemented a comprehensive lazy loading optimization system for the YAZE overworld editor that dramatically reduces ROM loading time by only building essential maps initially and deferring the rest until needed.
|
||||
|
||||
## Performance Problem Identified
|
||||
|
||||
### Before Optimization
|
||||
- **Total Loading Time**: ~2.9 seconds
|
||||
- **LoadOverworldMaps**: 2835.82ms (99.4% of loading time)
|
||||
- **All other operations**: ~17ms (0.6% of loading time)
|
||||
|
||||
### Root Cause
|
||||
The `LoadOverworldMaps()` method was building all 160 overworld maps in parallel, but each individual `BuildMap()` call was expensive (~17.7ms per map on average), making the total time ~2.8 seconds even with parallelization.
|
||||
|
||||
## Solution: Selective Map Building + Lazy Loading
|
||||
|
||||
### 1. Selective Map Building
|
||||
Only build the first 8 maps of each world initially:
|
||||
- **Light World**: Maps 0-7 (essential starting areas)
|
||||
- **Dark World**: Maps 64-71 (essential dark world areas)
|
||||
- **Special World**: Maps 128-135 (essential special areas)
|
||||
- **Total Essential Maps**: 24 out of 160 maps (15%)
|
||||
|
||||
### 2. Lazy Loading System
|
||||
- **On-Demand Building**: Remaining 136 maps are built only when accessed
|
||||
- **Automatic Detection**: Maps are built when hovered over or selected
|
||||
- **Seamless Integration**: No user-visible difference in functionality
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Core Changes
|
||||
|
||||
#### 1. Overworld Class (`overworld.h/cc`)
|
||||
```cpp
|
||||
// Added method for on-demand map building
|
||||
absl::Status EnsureMapBuilt(int map_index);
|
||||
|
||||
// Modified LoadOverworldMaps to only build essential maps
|
||||
absl::Status LoadOverworldMaps() {
|
||||
// Build only first 8 maps per world
|
||||
constexpr int kEssentialMapsPerWorld = 8;
|
||||
// ... selective building logic
|
||||
}
|
||||
```
|
||||
|
||||
#### 2. OverworldMap Class (`overworld_map.h`)
|
||||
```cpp
|
||||
// Added built state tracking
|
||||
auto is_built() const { return built_; }
|
||||
void SetNotBuilt() { built_ = false; }
|
||||
```
|
||||
|
||||
#### 3. OverworldEditor Class (`overworld_editor.cc`)
|
||||
```cpp
|
||||
// Added on-demand building to map access points
|
||||
absl::Status CheckForCurrentMap() {
|
||||
// ... existing logic
|
||||
RETURN_IF_ERROR(overworld_.EnsureMapBuilt(current_map_));
|
||||
}
|
||||
|
||||
void EnsureMapTexture(int map_index) {
|
||||
// Ensure map is built before creating texture
|
||||
auto status = overworld_.EnsureMapBuilt(map_index);
|
||||
// ... texture creation
|
||||
}
|
||||
```
|
||||
|
||||
### Performance Monitoring
|
||||
Added detailed timing for each operation in `LoadOverworldData`:
|
||||
- `LoadTileTypes`
|
||||
- `LoadEntrances`
|
||||
- `LoadHoles`
|
||||
- `LoadExits`
|
||||
- `LoadItems`
|
||||
- `LoadOverworldMaps` (now optimized)
|
||||
- `LoadSprites`
|
||||
|
||||
## Expected Performance Improvement
|
||||
|
||||
### Theoretical Improvement
|
||||
- **Before**: Building all 160 maps = 160 × 17.7ms = 2832ms
|
||||
- **After**: Building 24 essential maps = 24 × 17.7ms = 425ms
|
||||
- **Time Saved**: 2407ms (85% reduction in map building time)
|
||||
- **Expected Total Loading Time**: ~500ms (down from 2900ms)
|
||||
|
||||
### Real-World Benefits
|
||||
1. **Faster ROM Opening**: 80%+ reduction in initial loading time
|
||||
2. **Responsive UI**: No more 3-second freeze when opening ROMs
|
||||
3. **Progressive Loading**: Maps load smoothly as user navigates
|
||||
4. **Memory Efficient**: Only essential maps consume memory initially
|
||||
|
||||
## Technical Advantages
|
||||
|
||||
### 1. Non-Breaking Changes
|
||||
- All existing functionality preserved
|
||||
- No changes to user interface
|
||||
- Backward compatible with existing ROMs
|
||||
|
||||
### 2. Intelligent Caching
|
||||
- Built maps are cached and reused
|
||||
- No redundant building of the same map
|
||||
- Automatic cleanup of unused resources
|
||||
|
||||
### 3. Thread Safety
|
||||
- On-demand building is thread-safe
|
||||
- Proper mutex protection for shared resources
|
||||
- No race conditions in parallel map access
|
||||
|
||||
## User Experience Impact
|
||||
|
||||
### Immediate Benefits
|
||||
- **ROM Opening**: Near-instant startup (500ms vs 2900ms)
|
||||
- **Navigation**: Smooth map transitions with minimal loading
|
||||
- **Memory Usage**: Reduced initial memory footprint
|
||||
- **Responsiveness**: UI remains responsive during loading
|
||||
|
||||
### Transparent Operation
|
||||
- Maps load automatically when needed
|
||||
- No user intervention required
|
||||
- Seamless experience for all editing operations
|
||||
- Progressive loading indicators can be added later
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
### Potential Optimizations
|
||||
1. **Predictive Loading**: Pre-load adjacent maps based on user navigation patterns
|
||||
2. **Background Processing**: Build non-essential maps in background threads
|
||||
3. **Memory Management**: Implement LRU cache for built maps
|
||||
4. **Progress Indicators**: Show loading progress for better user feedback
|
||||
|
||||
### Monitoring and Metrics
|
||||
- Track which maps are accessed most frequently
|
||||
- Monitor actual performance improvements
|
||||
- Identify additional optimization opportunities
|
||||
- Measure memory usage patterns
|
||||
|
||||
## Conclusion
|
||||
|
||||
The lazy loading optimization successfully addresses the primary performance bottleneck in YAZE's ROM loading process. By building only essential maps initially and deferring the rest until needed, we achieve an 80%+ reduction in loading time while maintaining full functionality and user experience.
|
||||
|
||||
This optimization makes YAZE significantly more responsive and user-friendly, especially for users working with large ROMs or frequently switching between different ROM files.
|
||||
@@ -1,104 +0,0 @@
|
||||
# Overworld Optimization Status Update
|
||||
|
||||
## Current Performance Analysis
|
||||
|
||||
Based on the latest performance report:
|
||||
|
||||
```
|
||||
CreateOverworldMaps 1 148.42 148.42
|
||||
CreateInitialTextures 1 4.49 4.49
|
||||
CreateTilemap 1 4.70 4.70
|
||||
CreateBitmapWithoutTexture_Graphics1 0.24 0.24
|
||||
LoadOverworldData 1 2849.67 2849.67
|
||||
AssembleTiles 1 10.35 10.35
|
||||
CreateOverworldMapObjects 1 0.74 0.74
|
||||
DecompressAllMapTiles 1 1.40 1.40
|
||||
CreateBitmapWithoutTexture_Tileset1 3.69 3.69
|
||||
Overworld::Load 2 5724.38 2862.19
|
||||
```
|
||||
|
||||
## Key Findings
|
||||
|
||||
### ✅ **Successful Optimizations**
|
||||
1. **Decompression Fixed**: `DecompressAllMapTiles` is now only 1.40ms (was the bottleneck before)
|
||||
2. **Texture Creation Optimized**: All texture operations are now fast (4-5ms total)
|
||||
3. **Overworld Not Broken**: Fixed the parallel decompression issues that were causing corruption
|
||||
|
||||
### 🎯 **Real Bottleneck Identified**
|
||||
The actual bottleneck is **`LoadOverworldData`** at **2849.67ms (2.8 seconds)**, not the decompression.
|
||||
|
||||
### 📊 **Performance Breakdown**
|
||||
- **Total Overworld::Load**: 2862.19ms (2.9 seconds)
|
||||
- **LoadOverworldData**: 2849.67ms (99.5% of total time!)
|
||||
- **All other operations**: ~12.5ms (0.5% of total time)
|
||||
|
||||
## Root Cause Analysis
|
||||
|
||||
The `LoadOverworldData` phase includes:
|
||||
1. `LoadTileTypes()` - Fast
|
||||
2. `LoadEntrances()` - Fast
|
||||
3. `LoadHoles()` - Fast
|
||||
4. `LoadExits()` - Fast
|
||||
5. `LoadItems()` - Fast
|
||||
6. **`LoadOverworldMaps()`** - This is the bottleneck (already parallelized)
|
||||
7. `LoadSprites()` - Fast
|
||||
|
||||
The issue is that `LoadOverworldMaps()` calls `OverworldMap::BuildMap()` for all 160 maps in parallel, but each `BuildMap()` call is still expensive.
|
||||
|
||||
## Optimization Strategy
|
||||
|
||||
### Phase 1: Detailed Profiling (Immediate)
|
||||
Added individual timing for each operation in `LoadOverworldData` to identify the exact bottleneck:
|
||||
|
||||
```cpp
|
||||
{
|
||||
core::ScopedTimer tile_types_timer("LoadTileTypes");
|
||||
LoadTileTypes();
|
||||
}
|
||||
|
||||
{
|
||||
core::ScopedTimer entrances_timer("LoadEntrances");
|
||||
RETURN_IF_ERROR(LoadEntrances());
|
||||
}
|
||||
// ... etc for each operation
|
||||
```
|
||||
|
||||
### Phase 2: Optimize BuildMap Operations (Next)
|
||||
The `OverworldMap::BuildMap()` method is likely doing expensive operations:
|
||||
- Graphics loading and processing
|
||||
- Palette operations
|
||||
- Tile assembly
|
||||
- Bitmap creation
|
||||
|
||||
### Phase 3: Lazy Loading (Future)
|
||||
Only build maps that are immediately needed:
|
||||
- Build first 4-8 maps initially
|
||||
- Build remaining maps on-demand when accessed
|
||||
- Use background processing for non-visible maps
|
||||
|
||||
## Current Status
|
||||
|
||||
✅ **Fixed Issues:**
|
||||
- Overworld corruption resolved (reverted to sequential decompression)
|
||||
- Decompression performance restored (1.4ms)
|
||||
- Texture creation optimized
|
||||
|
||||
🔄 **Next Steps:**
|
||||
1. Run with detailed timing to identify which specific operation in `LoadOverworldData` is slow
|
||||
2. Optimize the `OverworldMap::BuildMap()` method
|
||||
3. Implement lazy loading for non-essential maps
|
||||
|
||||
## Expected Results
|
||||
|
||||
With the detailed timing, we should see something like:
|
||||
```
|
||||
LoadTileTypes 1 ~5ms
|
||||
LoadEntrances 1 ~50ms
|
||||
LoadHoles 1 ~20ms
|
||||
LoadExits 1 ~100ms
|
||||
LoadItems 1 ~200ms
|
||||
LoadOverworldMaps 1 ~2400ms <-- This will be the bottleneck
|
||||
LoadSprites 1 ~100ms
|
||||
```
|
||||
|
||||
This will allow us to focus optimization efforts on the actual bottleneck rather than guessing.
|
||||
Reference in New Issue
Block a user