Performance Tips¶
Optimize TrueFidelity Desktop for smooth operation, responsive playback, and efficient analysis by following these guidelines based on the actual system capabilities.
Hardware Recommendations¶
Minimum Requirements¶
- CPU: 4 cores, 2.5 GHz or higher
- Memory: 8 GB RAM (16 GB for Docker operations)
- Storage: 50 GB free space on SSD
- Graphics: Any GPU supporting hardware acceleration
- OS: Windows 10/11, macOS 10.15+, or Linux with Docker support
Recommended Configuration¶
- CPU: 6-8 cores, 3 GHz or higher for better multi-container performance
- Memory: 16 GB RAM minimum, 32 GB recommended for large BLF files
- Storage: NVMe SSD with 100+ GB free space for logs and Docker images
- Network: Stable connection for Docker image downloads
Docker Configuration¶
Since TrueFidelity uses Docker for ECU simulation, Docker performance directly impacts system performance.
Docker Desktop Settings¶
- Memory Allocation:
- Open Docker Desktop settings
- Increase memory to at least 8 GB
- For large systems, allocate 12-16 GB
-
Leave 4-8 GB for the host OS
-
CPU Allocation:
- Allocate at least 4 CPU cores to Docker
- For multi-ECU systems, increase to 6-8 cores
-
Balance with host system needs
-
Disk Space:
- Ensure Docker has adequate disk space
- Regular cleanup:
docker system prune -a - Monitor image sizes:
docker images
RTOS ECU Considerations¶
When working with Zephyr or FreeRTOS ECUs: - Terminal access is not available for RTOS-based ECUs - Use ECU Console panel for log viewing instead - Enable GDB debugging in ECU properties for detailed analysis - Console logging works with all ECU types
File and Data Management¶
BLF File Optimization¶
- File Location:
- Store BLF files on local SSD, not network drives
- Keep working files on fastest available storage
-
Archive completed analyses to slower storage
-
File Size Considerations:
- Files under 500 MB: Smooth performance
- 500 MB - 2 GB: May experience some delays
- Over 2 GB: Consider splitting or filtering before import
-
Maximum tested: 4 GB (performance degrades significantly)
-
Pre-processing:
- Filter unnecessary CAN IDs before creating BLF
- Reduce capture duration when possible
- Use appropriate sampling rates
System Files¶
- Keep system JSON files small and focused
- Avoid excessive numbers of ECUs (10+ may impact performance)
- Organize systems by project or test scenario
Playback Performance¶
Signal Player Optimization¶
- Before Playback:
- Close unnecessary panels
- Clear Network Traffic panel if full
-
Limit selected signals in Signal Viewer
-
During Playback:
- Start with 1x speed for large files
- Use pause/resume instead of stop/start
-
Monitor memory usage in system tools
-
Signal Selection:
- Select only essential signals for charting
- Deselect signals when not needed
- Group related signals for efficiency
Network Traffic Panel¶
- Managing Data Flow:
- Use filters to reduce displayed frames
- Clear panel periodically during long sessions
-
Disable auto-scroll if reviewing specific frames
-
Filtering Best Practices:
- Filter by CAN ID for focused analysis
- Apply filters before starting playback
- Remove filters when no longer needed
UI and Layout Performance¶
Panel Management¶
- Docking Configuration:
- Keep frequently used panels docked
- Close panels not in use
- Avoid excessive panel stacking
-
Use stable layouts to reduce redrawing
-
Mode Switching:
- Stay in one mode during intensive operations
- Save work before switching modes
- Allow transitions to complete before interacting
System Canvas¶
- Canvas Performance:
- Limit number of visible ECUs and networks
- Avoid excessive connection lines
- Use zoom appropriately (50-150% optimal)
-
Minimize canvas redraws during edits
-
Building Systems:
- Build smaller subsystems first
- Test with fewer ECUs initially
- Add complexity gradually
Signal Chart Optimization¶
Chart Settings¶
- Time Window:
- Use appropriate time windows (10-60 seconds)
- Avoid extremely long windows with many signals
-
Adjust based on data density
-
Signal Count:
- Limit to 4-6 signals simultaneously
- Use multiple charts for different signal groups
-
Remove signals when analysis complete
-
Visual Settings:
- Enable grid only when needed
- Use auto-scale judiciously
- Export charts promptly to free memory
Export Performance¶
CSV Export¶
- Best Practices:
- Export smaller time ranges
- Limit number of signals
- Close other applications during export
-
Use local storage for output files
-
Large Exports:
- Break into multiple smaller exports
- Export during low-activity periods
- Monitor disk space availability
BLF Export¶
- Generally faster than CSV
- Maintains data integrity
- Suitable for archival purposes
- Can be re-imported for future analysis
System Maintenance¶
Regular Cleanup¶
- Docker Maintenance: ```bash # Remove stopped containers docker container prune
# Remove unused images docker image prune -a
# Complete cleanup (use carefully) docker system prune -a --volumes ```
- Application Cleanup:
- Clear browser cache periodically
- Remove old export files
- Archive completed projects
- Clean temporary directories
Performance Monitoring¶
- System Tools:
- Windows: Task Manager, Resource Monitor
- macOS: Activity Monitor
-
Linux: htop, docker stats
-
Key Metrics:
- CPU usage by Docker and Electron
- Memory consumption trends
- Disk I/O during playback
- Network usage (if using remote storage)
Troubleshooting Performance Issues¶
Common Problems and Solutions¶
| Symptom | Possible Causes | Solutions |
|---|---|---|
| Slow application startup | Docker not running, large saved layout | Start Docker first, reset window layout |
| Playback stutters | Large BLF file, insufficient memory | Reduce playback speed, increase Docker memory |
| System build fails | Insufficient resources, Docker issues | Check Docker status, free up resources |
| UI freezes | Too many panels open, memory pressure | Close unused panels, restart application |
| Export takes forever | Large dataset, slow storage | Export smaller ranges, use SSD |
| Chart updates slowly | Too many signals, auto-scale enabled | Reduce signals, use fixed scale |
Performance Diagnostics¶
When experiencing issues:
-
Check Docker Status:
bash docker info docker stats --no-stream -
Monitor Resources:
- CPU usage should stay below 80%
- Memory usage should leave 2-4 GB free
-
Disk I/O should not be constantly maxed
-
Application Logs:
- Check browser console (F12)
- Review Docker container logs
- Look for error messages
Best Practices Summary¶
Do's¶
- ✅ Use local SSD storage for active files
- ✅ Allocate sufficient Docker resources
- ✅ Close unnecessary panels during intensive operations
- ✅ Filter data before analysis
- ✅ Export in manageable chunks
- ✅ Maintain your Docker environment
Don'ts¶
- ❌ Work with files on network drives
- ❌ Select all signals at once
- ❌ Leave Docker with default memory settings
- ❌ Ignore system resource warnings
- ❌ Try to load extremely large files without splitting
- ❌ Run multiple instances simultaneously
Platform-Specific Tips¶
Windows¶
- Ensure WSL 2 is properly configured for Docker
- Disable Windows Defender scanning for Docker directories
- Use native Windows paths, not WSL paths
macOS¶
- Grant necessary permissions to Docker Desktop
- Increase Docker resources in Docker Desktop preferences
- Use APFS formatted drives for best performance
Linux¶
- Run Docker with appropriate user permissions
- Consider using native Docker instead of Docker Desktop
- Ensure sufficient swap space configured
Getting Help¶
If performance issues persist after following these guidelines:
- Document the issue with specific steps to reproduce
- Note system specifications and Docker configuration
- Capture relevant logs and error messages
- Contact support with this information
Related Documentation¶
- System Requirements - Detailed hardware and software requirements
- Docker Setup - Configuring Docker for TrueFidelity
- Troubleshooting - Common issues and solutions
- File Compatibility - Optimal file formats and sizes