51–60 of 285 posts
For those wanting a real world example where this can be useful: I am writing a static site generator. When run in "watch" mode, it deletes everything and starts over (I'd like to reduce these with partial updates but can't always do it). Moving that cleanup to a thread would make "watch" more responsive.
If freeing the data structure in question takes this long, how much time are you wasting duplicating the data structure?
I’m actually very curious why it takes this long; is Rust memseting the buffer when dropping it? Edit: it seems like turning on optimizations seems to improve the situation quite a bit. Not sure why they were profiling the debug build.
I'm not seeing that on my local machine? Were you comparing on the Playground which would be quite variable in its results?
> cargo build
Compiling foo v0.1.0 (/private/tmp/foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.42s
> ./target/debug/foo
drop in another thread 52.121µs
drop in this thread 514.687233ms
>
>
> cargo build --release
Compiling foo v0.1.0 (/private/tmp/foo)
Finished release [optimized] target(s) in 0.47s
> ./target/release/foo
drop in another thread 48.418µs
drop in this thread 548.005373msI used to do this sometimes with C++ when I realized that clearing out a vector with lots of objects was slow. Is Rust basically based on unique_ptr? One problem with this approach was that you still had to wait for these threads when the application would shut down.
Out of curiosity, how did you do that in C++?
This is the standard problem with tracing data structures to free them. You frequently run into it with systems based on malloc/free or reference counting. The underlying problem is that freeing the structure takes time proportional to the number of pointers in the structure it has to chase. Generational/compacting GC has the opposite problem. Garbage collection takes time proportional to the live set, and the amount…
> This is the standard problem with tracing data structures to free them. You frequently run into it with systems based on malloc/free or reference counting. The underlying problem is that freeing the structure takes time proportional to the number of pointers in the structure it has to chase. That doesn't seem to make intuitive sense. A GC has the same problem. A garbage collector has to traverse the data structure…
Isn't that incompatible with RAII though?
Oh my good god. I'm hoping this is down to developer naivety rather than being a feature of rust.
2) but somewhere somehow this object will deallocate, so his trick of putting it to another thread would work if the deal location takes awhile. Same for cpp if you have a massive object in a unique ptr. So it’s not a rust issue
fn get_len1(things: HeavyThings) -> usize {
things.len()
}
fn get_len2(things: HeavyThings) -> usize {
let len = things.len();
thread::spawn(move || drop(things));
len
}
See also this comment by chowells: https://news.ycombinator.com/item?id=23362925
Earlier quoted context omitted.
I’m actually very curious why it takes this long; is Rust memseting the buffer when dropping it? Edit: it seems like turning on optimizations seems to improve the situation quite a bit. Not sure why they were profiling the debug build.
> it seems like turning on optimizations seems to improve the situation quite a bit. I'm not seeing that on my local machine? Were you comparing on the Playground which would be quite variable in its results? > cargo build Compiling foo v0.1.0 (/private/tmp/foo) Finished dev [unoptimized + debuginfo] target(s) in 0.42s > ./target/debug/foo drop in another thread 52.121µs drop in this thread 514.687233ms > > > cargo b…
Earlier quoted context omitted.
>A profiler can tell you when you should drop asynchronously Is there any profiler that does this today? What are the drawbacks with asynchronous drops?
See some discussion here: https://www.reddit.com/r/rust/comments/gntv7l/dropping_heavy...
Earlier quoted context omitted.
I’m actually very curious why it takes this long; is Rust memseting the buffer when dropping it? Edit: it seems like turning on optimizations seems to improve the situation quite a bit. Not sure why they were profiling the debug build.
> Edit: it seems like turning on optimizations seems to improve the situation quite a bit. Not sure why they were profiling the debug build. This is the most important point in the thread, since it invalidates the results for most purposes.