From 759fa4cf6fe17c46490612463f048f692f03a10c Mon Sep 17 00:00:00 2001
From: Michael Kirk <michael.code@endoftheworl.de>
Date: Mon, 25 Nov 2024 20:00:14 -0800
Subject: [PATCH] update to i_overlay 1.9

Note there is a serious performance regression for larger geometries in our benchmarks vs. 1.8.

    cargo bench --bench=boolean_ops -- --baseline=main
    ... small ones are fine, but big ones have huge regression
    Circular polygon boolean-ops/bops::union/1024
                            time:   [4.3625 ms 4.3922 ms 4.4093 ms]
                            change: [+1.7493% +2.4971% +3.2026%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Circular polygon boolean-ops/bops::intersection/2048
                            time:   [14.057 ms 14.115 ms 14.157 ms]
                            change: [+9.0224% +10.438% +11.658%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Circular polygon boolean-ops/bops::union/2048
                            time:   [14.012 ms 14.071 ms 14.134 ms]
                            change: [+11.212% +12.141% +13.317%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Found 1 outliers among 10 measurements (10.00%)
      1 (10.00%) high severe
    Circular polygon boolean-ops/bops::intersection/4096
                            time:   [360.66 ms 361.18 ms 361.83 ms]
                            change: [+709.38% +713.12% +716.34%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Found 2 outliers among 10 measurements (20.00%)
      2 (20.00%) high severe
    Circular polygon boolean-ops/bops::union/4096
                            time:   [361.35 ms 361.71 ms 362.13 ms]
                            change: [+710.58% +713.76% +716.59%] (p = 0.00 < 0.05)
                            Performance has regressed.

Likely this is because there is a new heuristic for "solver" strategies
based on how big your input is - the cliff likely indicates the switch
to one of the solvers used for larger inputs.

See https://github.com/iShape-Rust/iOverlay/issues/13

There are significant gains with some "real world" data, e.g. urshrei's cascaded
union tests:
https://github.com/georust/geo/issues/1273#issuecomment-2500778924

I'm more inclined to trust that more realistic data over the synthetic
geometries we use in our benchmarks.

Plus, I'd prefer to leave in performance twiddling to upstream and
contribute changes there rather than fine-tuning things at our own
call sites.
---
 geo/Cargo.toml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/geo/Cargo.toml b/geo/Cargo.toml
index 7867e94e6..1c40d91ff 100644
--- a/geo/Cargo.toml
+++ b/geo/Cargo.toml
@@ -31,7 +31,7 @@ proj = { version = "0.27.0", optional = true }
 robust = "1.1.0"
 rstar = "0.12.0"
 serde = { version = "1.0", optional = true, features = ["derive"] }
-i_overlay = { version = "1.8.0, < 1.9.0", default-features = false }
+i_overlay = { version = "1.9.0, < 1.10.0", default-features = false }
 
 [dev-dependencies]
 approx = ">= 0.4.0, < 0.6.0"