search the Vec for small LazyIndexMaps

[samuelcolvin]

Instead of creating a HashMap when there are very few elements in the LazyIndexMap, just lookup the original Vec. We store and start from the position of the last find to improve performance in the common case that the input JSON matches the order of the model being constructed

the threshold is set to 16 based on the following benchmarks:

with hashmap

test lazy_map_lookup_1_10           ... bench:         903 ns/iter (+/- 50)
test lazy_map_lookup_2_20           ... bench:       1,726 ns/iter (+/- 54)
test lazy_map_lookup_3_50           ... bench:       4,171 ns/iter (+/- 43)
test lazy_map_lookup_4_100          ... bench:       8,187 ns/iter (+/- 129)
test lazy_map_lookup_5_200          ... bench:      16,547 ns/iter (+/- 197)
test lazy_map_lookup_6_500          ... bench:      39,541 ns/iter (+/- 1,299)
test lazy_map_lookup_7_1000         ... bench:      81,937 ns/iter (+/- 832)

vec best

test lazy_map_lookup_1_10           ... bench:         613 ns/iter (+/- 8)
test lazy_map_lookup_2_20           ... bench:       1,210 ns/iter (+/- 11)
test lazy_map_lookup_3_50           ... bench:       2,870 ns/iter (+/- 66)
test lazy_map_lookup_4_100          ... bench:       5,573 ns/iter (+/- 177)
test lazy_map_lookup_5_200          ... bench:      11,138 ns/iter (+/- 358)
test lazy_map_lookup_6_500          ... bench:      27,648 ns/iter (+/- 418)
test lazy_map_lookup_7_1000         ... bench:      55,863 ns/iter (+/- 2,435)

vec worst

test lazy_map_lookup_1_10           ... bench:         836 ns/iter (+/- 14)
test lazy_map_lookup_2_20           ... bench:       2,057 ns/iter (+/- 29)
test lazy_map_lookup_3_50           ... bench:      10,068 ns/iter (+/- 138)
test lazy_map_lookup_4_100          ... bench:      35,480 ns/iter (+/- 449)
test lazy_map_lookup_5_200          ... bench:      99,785 ns/iter (+/- 2,516)
test lazy_map_lookup_6_500          ... bench:     667,054 ns/iter (+/- 8,748)
test lazy_map_lookup_7_1000         ... bench:   2,862,108 ns/iter (+/- 46,693)

vec random

test lazy_map_lookup_1_10           ... bench:         787 ns/iter (+/- 106)
test lazy_map_lookup_2_20           ... bench:       1,687 ns/iter (+/- 215)
test lazy_map_lookup_3_50           ... bench:       7,084 ns/iter (+/- 795)
test lazy_map_lookup_4_100          ... bench:      22,411 ns/iter (+/- 3,636)
test lazy_map_lookup_5_200          ... bench:      61,810 ns/iter (+/- 6,717)
test lazy_map_lookup_6_500          ... bench:     389,558 ns/iter (+/- 24,424)
test lazy_map_lookup_7_1000         ... bench:   1,597,234 ns/iter (+/- 89,720)

[codecov]

Codecov Report

Merging #55 (497a5ad) into main (849d5b8) will increase coverage by 2.09%.
Report is 1 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
+ Coverage   93.03%   95.12%   +2.09%     
==========================================
  Files           8        8              
  Lines        1048     1067      +19     
==========================================
+ Hits          975     1015      +40     
+ Misses         73       52      -21     

Files	Coverage Δ
src/lazy_index_map.rs	97.72% <100.00%> (+29.23%)	⬆️
src/python.rs	93.69% <100.00%> (+0.23%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ce40b3...497a5ad. Read the comment docs.

[codspeed-hq]

CodSpeed Performance Report

Merging #55 will not alter performance

_{Comparing vec-small-LazyIndexMap (497a5ad) with main (1ce40b3)}

Summary

✅ 39 untouched benchmarks

🆕 3 new benchmarks

Benchmarks breakdown

	Benchmark	main	vec-small-LazyIndexMap	Change
🆕	lazy_map_lookup_1_10	N/A	29.4 µs	N/A
🆕	lazy_map_lookup_3_50	N/A	233.2 µs	N/A
🆕	lazy_map_lookup_2_20	N/A	90.2 µs	N/A

[samuelcolvin]

@davidhewitt I'm interested if you think there's something faster than Arc<Mutex<...>> we can use where while still satisfying the requirement of implementing Sync?

[davidhewitt]

If last_find is not a problem for correctness, could just use UnsafeCell? E.g. if worst case is that the field isn't found from last_find to the end, and then the start is searched, it's probably suitable.

[davidhewitt]

(using UnsafeCell you'll need to wrap it like struct LastFind(UnsafeCell<usize>) and unsafe impl Sync for LastFind.)

[davidhewitt]

Also AtomicUsize is the safe option which will still be much faster than a mutex and on some platforms maybe no different to UnsafeCell, might want the portable_atomic crate as a dependency given the range of platforms this might be packaged on.

[davidhewitt]

Staring at this, I sort of wonder if this last_find logic should be moved into a function pub fn get_hint<Q: ?Sized>(&self, key: &Q, last_find: Option<usize>) -> Option<(&V, usize)> which returns the hint for the next lookup.

That way the hint can be a local stack variable and not an atomic part of the datastructure. But it does push the complexity downstream.

Going further, maybe this is better abstracted into a a struct OrderedGetter { map: &LazyIndexMap, last_find: usize } which looks in the map with a pub fn get<Q: ?Sized>(&mut self, key: &Q) -> Option<&V> - i.e. &mut - so by doing this is explicitly optimized for the order-preserving read.

[davidhewitt]

We spoke about this offline; will keep this as-is for now but maybe can remove the atomic later.

[samuelcolvin]

We decided on a call to stick with this to avoid churn in pydantic-core.