## PIL Image Processing is Dominated by C Extensions

**Evidence**: Profiling showed 95%+ of runtime in C extension calls (ImagingCore.resize, ImagingEncoder.encode, ImagingDecoder.decode). Only 5% in Python wrapper code, mostly import overhead.

**Implication**: Targeting PIL-heavy workloads has minimal optimization potential. Operations are already heavily optimized at the C level.

**Action for future sessions**: Avoid benchmarks that primarily exercise external C libraries. Focus on Odoo's own Python code.

## numpy Array Creation Can Be Slower Than Native Operations

**Evidence**: Experiment 1 replaced PIL's per-pixel operations with numpy array creation. Result: 11% SLOWER CPU, 335% MORE memory.

**Root cause**: numpy creates large intermediate arrays. For 2048x2048 RGB images, this is 12.5 MB. The original PIL putpixel loop only cost 0.014s (0.26% of runtime).

**Lesson**: "Obvious" optimizations (using numpy for array operations) can backfire when the original operation is already implemented efficiently in C. Always profile after changes.

## Better Targets for Odoo Optimization

Based on codebase analysis, promising areas with actual Python algorithmic work:

1. **ORM cache management** (`odoo/tools/cache.py`, 384 lines)
   - Tests: `odoo/addons/base/tests/test_cache.py`, `test_ormcache.py`
   - Pure Python cache key computation, lookup, invalidation logic

2. **Query building** (`odoo/tools/query.py`, 276 lines)
   - Tests: `odoo/addons/base/tests/test_query.py`
   - SQL query construction and optimization logic

3. **Translation system** (`odoo/tools/translate.py`, 1991 lines)
   - Large module with text processing

4. **Misc utilities** (`odoo/tools/misc.py`, 1967 lines)
   - General utility functions, likely has algorithmic patterns

These modules have existing test suites that can serve as benchmarks, avoiding the need to create synthetic benchmarks.
