Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> when I saw the example code I automatically thought "that's definitely not a good way to make a copy"

Sure but that's not really the point, it's just an easy way to trigger the issue. If you look at the original issue[0], the initial use case is merging two maps:

    let first_map: HashMap<u64, _> = (0..900000).map(|i| (i, ())).collect();
    let second_map: HashMap<u64, _> = (900000..1800000).map(|i| (i, ())).collect();
> The user wants to merge the hash maps, and does so naïvely,

    let mut merged = first_map;
    merged.extend(second_map);
> Time for merge when second_map is shuffled: 0.4s

> Time for merge when second_map is not shuffled: 40.s (x100 amplification)

The example in TFA is a simplified/boiled down to the barest version exposing the issue from a more real-world case of "was transforming one HashMap into another (with natural language words as keys), iterating over the keys of the first HashMap, inserting them in the second with different values."

> I'm not familiar with Rust, but I assume the class contains a special cloning method which does something more like a memcpy()?

You can't memcpy the hashmap since it could contain non-trivial keys or values (e.g. refcounted heap allocations)[1], but you could clone() it for a one-shot copy. As noted above you're missing the forest for the trees though, that's just an easy trigger case, the point is not cloning maps.

[0] https://github.com/rust-lang/rust/issues/36481

[1] and the hashmap is mostly a pointer to a big holding the keys, values and hashes, which you probably don't want to share



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: