`bounding_rect` comsume a lot of cpu?? about geo HOT 23 CLOSED

the flame graph file

from geo.

core::clone::impls::<impl core::clone::Clone for f64>::clone (600 samples, 1.19%)

You're building with --release, right?

core::option::Option<&T>::cloned (12,376 samples, 24.59%)

Wat

from geo.

@lnicola I am building release version,otherwise all operation should slow

from geo.

That flamegraph makes no sense to me. get_bounding_rect is pretty simple, and we don't capture stack traces (backtrace::backtrace::trace_unsynchronized) there, it can't even panic.

from geo.

That's Linux, right? How did you get the flamegraph? Are you using -Z build-std or any profile overrides ([profile.dev.*] etc.)?

from geo.

yes it's linux, I am using https://crates.io/crates/pprof to pprof

from geo.

Maybe this?

Note: If you're using lld or mold on Linux, you must use the --no-rosegment flag. Otherwise perf will not be able to generate accurate stack traces (explanation).

from geo.

I change the config still the same result.

[build]
linker = "clang"
rustflags = [ "-C", "link-arg=-fuse-ld=mold" ,  "-Clink-arg=-Wl,--no-rosegment"]
jobs = 4
incremental = false

from geo.

Maybe you can give cargo-flamegraph a try? I don't have other ideas right now.

from geo.

@lnicola yes ,still installing toolchain.

from geo.

I run twice I get the same error

2024-07-17T07:14:52.627767Z  INFO          task_runner ThreadId(297) gis::st_intersects2: index filter out is 3836,still need full intersects is 4
[ perf record: Woken up 25358 times to write data ]

Warning:
Processed 482187 events and lost 42 chunks!

Check IO/CPU overload!

Warning:
1 out of order events recorded.

[ perf record: Captured and wrote 6761.545 MB perf.data (425990 samples) ]
failed to sample program

from geo.

Hmm, that's normally just a warning, and it does produce a perf.data file, which you can process. But you can use something like -F 498 to reduce the sampling frequency.

from geo.

I think capture pprof succeeful.

from geo.

cargo-flamegraph capture less stack frame??

from geo.

I'm still confused about the flame graph, TBH.

Maybe it just gets called too many times? See https://docs.rs/rstar/latest/rstar/primitives/struct.CachedEnvelope.html, if rstar calls envelope a lot of times, and your polygons are large, I can see get_bounding_rect becoming a bottleneck.

We could also do .copied() here, but there's no reason for clone() to be slow.

from geo.

Yes , I think envelope need called 2 million times.

from geo.

Can you try to insert CachedEnvelope<Geometry<f64>> into your rstar tree?

2M times isn't even a lot...

from geo.

let me see

from geo.

No I don't think so.

from geo.

Unless you can produce a test case I can run, I'll leave this for someone who actually managed to use rstar 😅.

from geo.

@lnicola thanks I will try

from geo.

I use this code to run https://github.com/yuyang-ok/geo_parse_bounding_performance.
run quit fast.

warning: unused config key `build.linker` in `/home/yuyang/.cargo/config`
   Compiling geo_bounding_rect_performance v0.1.0 (/home/yuyang/geo_parse_bounding_performance)
    Finished `release` profile [optimized] target(s) in 1.35s
     Running `target/release/geo_bounding_rect_performance`
parse geometry and bounding_rect 10s total run:3022800
bounding_rect 1s total run:3022800

from geo.

Hmm, it might look different if you include the tree building.

from geo.