Database I/O is the primary bottleneck for spell checking throughput. Since Myanmar text reuses a relatively small set of common syllables and words, caching is highly effective, and a well-tuned cache can eliminate 90%+ of SQLite reads. This guide covers how to size caches for your workload.
Overview
The caching system provides:
- LRU Cache: Least Recently Used eviction strategy
- CacheManager: Unified cache management
AlgorithmCacheConfig
Note: There are two cache config classes in the library:
myspellchecker.core.config.AlgorithmCacheConfig (Pydantic model) — used with SpellCheckerConfig for algorithm-level cache sizing
myspellchecker.utils.cache.CacheConfig (dataclass) — used for low-level cache instance configuration with maxsize and name
Configure caching behavior for different lookup types:
Configuration Options
Creating Cache Configs
LRU Cache
Least Recently Used cache with fixed size:
LRU Eviction
When the cache is full, the least recently accessed item is evicted:
CacheManager
Unified cache management for multiple cache instances:
Integration with SpellChecker
Caching is automatically configured via SpellCheckerConfig:
What’s Cached
1. Size Appropriately
2. Monitor Hit Rates
4. Clear on Data Changes
Thread Safety
All cache implementations are thread-safe:
Minimizing Cache
For debugging or testing with minimal caching:
Do not set cache sizes to 0. LRUCache requires maxsize >= 1 and raises ValueError otherwise. Use 1 for the smallest possible cache.
Best Practices
- Start with defaults: The default configuration works well for most cases
- Monitor hit rates: Use
SpellChecker.cache_stats() to identify underperforming caches
- Size for working set: Cache should fit typical vocabulary in use
- Clear strategically: Clear cache when dictionary data changes
See Also