Skip to content

BytesMut::freeze is not zero-cost #401

@Jasper-Bekkers

Description

@Jasper-Bekkers

If self.kind() == KIND_VEC is true, freeze ends up calling vec.into() which appears to not be zero-cost at all, and ends up doing a huge memcpy somewhere in the bowels of Vec

image

Activity

Jasper-Bekkers

Jasper-Bekkers commented on Jun 28, 2020

@Jasper-Bekkers
Author

It looks like the original from_vec implementation didn't used to call into_boxed_slice before the refactoring in #298 https://github.com/tokio-rs/bytes/pull/298/files#diff-d272e47b868896a26bf5ddcfa9be0ea2L1836

fanatid

fanatid commented on Jul 12, 2020

@fanatid
Contributor

@Jasper-Bekkers out of interest, how you get this trace? Is there a way do nearly same on Linux?

Jasper-Bekkers

Jasper-Bekkers commented on Jul 12, 2020

@Jasper-Bekkers
Author

It's profiled with Superluminal Profiler; https://superluminal.eu I don't think it supports Linux yet.

added this to the v0.6 milestone on Oct 16, 2020
Matthias247

Matthias247 commented on Oct 17, 2020

@Matthias247
Contributor

By looking at it this comes from calling Vec::into_boxed_slice(), which calls Vec::shrink_to_fit().

That again means freeze is not zero cost if the BytesMut wasn't written up to it's capacity. If you reserve the exact amount upfront, it might not be an issue. If you split off anything upfront (which promotes to an Arc), then it also wouldn't be an issue.

This is all fixable. However a tricky question is whether people are all ok with unused memory in the BytesMut being "lost" while Bytes elements refer to a subset of it. For myself - I would be - given that I don't see Bytes as an ideal long term storage anyway and everyone should strive for releasing the chunks as soon as no longer required to avoid references keeping bigger buffers alive for longer than necessary.

Matthias247

Matthias247 commented on Oct 17, 2020

@Matthias247
Contributor

After thinking a bit more about it: I think we can solve this easily by adding an additional shrink_and_freeze() method for people which care about potential waste of memory, and make sure freeze() is always allocation free.

linked a pull request that will close this issue on Oct 18, 2020
removed this from the v0.6 milestone on Dec 15, 2020
Jasper-Bekkers

Jasper-Bekkers commented on Jan 25, 2022

@Jasper-Bekkers
Author

After thinking a bit more about it: I think we can solve this easily by adding an additional shrink_and_freeze() method for people which care about potential waste of memory, and make sure freeze() is always allocation free.

Did this ever end up getting implemented, and if so, should we close this issue? ☺️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @carllerche@Jasper-Bekkers@fanatid@Matthias247

      Issue actions

        BytesMut::freeze is not zero-cost · Issue #401 · tokio-rs/bytes