Comment by dnautics
6 days ago
> Can you give some examples? I've never ran into problems due to this.
If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted.
thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D
> If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted.
Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essential tool for optimisation.
The solution to this "unexpected performance regression" in rust is the same as it is in C, C++ and Zig: Stop heap allocating so much. Use primitive types, SSO types (SmartString and friends in rust) or memory arenas. Drop isn't the problem.
In zig the solution is to use an arena allocator. That’s about as easy as it gets. Maybe Rust also allows doing that, I don’t know.
You can use arenas in Rust, it's just not as trivial to swap allocators generally. But there are plenty of crates for it.
no, in zig it's never unexpected, because if you're freeing memory the freesite is known, it's a function call.
Right; because in zig the default behaviour is to leak memory. Rust adds an invisible free() call. Leaking is something you have to do explicitly.
I understand zig's philosophy here. But I prefer rust's default behaviour.
1 reply →