Does anyone know how would this work in Go?
Rust: Dropping heavy things in another thread can make your code 10000x faster
71–80 of 285 posts
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#72I 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.
You could have just one thread and to kill it at exit. Do not start new threads for each closure that drops object, send closures into one special thread instead.
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#73It seems that this would be a great reason to not pass the entire heavy object through your function, and to instead pass it as a reference. When passing an object (rather than a reference to an object) there's a lot more work going on both in function setup, and in object dropping. I'm not a rust guru, so I don't know the precise wording, but it's simple enough to realize that if this function, as claimed, must drop…
If your function takes a reference to the object, something still needs to free it.
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#74Earlier quoted context omitted.
> 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.
Not completely, it's still 2-3 orders of magnitude slower.
You're right, I expected it would make a bigger difference
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#75I'm not very familiar with Rust, but I don't understand why you wouldn't just use a reference-to-HeavyThing as the function argument, so that the object isn't moved and then dropped in the `get_size` function?
So the caller of the function still needs to free HeavyThing in the same thread.
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#76In other words, Rust's automagical memory deallocation is NOT a zero-cost abstraction: fn get_len1(things: HeavyThings) -> usize { things.len() } fn get_len2(things: HeavyThings) -> usize { let len = things.len(); thread::spawn(move || drop(things)); len } The OP shows an example in which a function like get_len2 is 10000x faster than a function like get_len1 for a hashmap with 1M keys. See also this comment by chowe…
No the zero-cost refers to the abstraction (and runtime cost), which still is zero-cost. Deallocating is part of the normal work load not the abstraction.
Also this isn't rust specific. Most (all?) RAII languages are affected and many GC approaches have this effect, too. Some do add additional abstraction to magically always or sometimes put the de-allocation into another thread.
But de-allocating in another thread is not generally good or bad. There are a lot of use-cases where doing so is rather bad or can't be done (in case TLS is involved). Rust and other similar RAII languages at least let you decide what you want to do.
Now it's (I think) generally known that certain kinds (not all) of GC do make some thinks simpler for GUI-like usage. Through they also tend to have less control.
Note that it's a common pattern for small user CLI facing tools (which are not GC'ed) to leak resources instead of cleaning them up properly. You can do so in rust too if you want but it's a potential problem for longer running applications.
Also here is a faster get `get_len` then both which is also more idiomatic rust then both:
``` fn get_len1(things: &HeavyThings) -> usize { things.len() } ```
If you have a certain thread (e.g. UI thread) in which you never want to do any cleanup work you can consider using a container like:
``` struct DropElsewhere(pub Option); impl Drop for DropElsewhere { fn drop(&mut self) { if let Some(value) = self.take() { thread::spawn(move || drop(value)); } } } ```
You can optimize this with `ManualDrop` to have close to zero-runtime overhead (removes the `take` and `if let` part).
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#77Oh my good god. I'm hoping this is down to developer naivety rather than being a feature of rust.
1) he should pass by reference to avoid the extra copy. So in his example yes it’s dev naivety 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
> avoid the extra copy
there is no copy happening here
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#78Contrived examples like this are ridiculous. Creating such a heavy thing is likely even more expensive than tearing it down. So unless you create it on a separate thread, you probably shouldn't be freeing it on a separate one. It's not going to solve your interactivity problem. If you are creating the object on a separate thread then it's already going to be natural to free it on a separate one too.
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#79Some important things I think people should note before blindly commenting: * The example code is obviously contrived. The real gist is that massive deallocations in the UI thread cause lag, which the example code proves. That very thing can easily happen in the real world. * I didn't see any difference on my machine between a debug build and a release build. * The example is preforming 1 _million_ deallocations. Tha…
This deallocation trick is neat but in C and C++ you could use a memory pool to do this.
In theory, you could also use a memory pool in Rust but I think the standard library uses malloc without some way of overriding this behaviour.
Re: Rust: Dropping heavy things in another thread can make your code 10000x faster
#80Earlier quoted context omitted.
> The only way to drop an extensively nested structure like this any faster than traversing it would be an arena allocator, and forgetting about the entire arena. Isn't that incompatible with RAII though?
You can handle this in Rust pretty neatly with lifetimes. There's a bunch of crates that do this. [1] [1] https://crates.io/crates/typed-arena
That's a neat library but as far as I can tell it doesn't avoid any traversal or cleanup code. It appears to delay the cleanup so it all happens at once. That's certainly useful, but if you have RAII the traversal still has to happen at some point.