Rounding functions in storage.rs differ a little, intentional?

[luukvanderduim]

Hi !

In impl Read::read() for StreamReader ( in psst-copre / src / player / storage.rs )

            let req_pos = round_down_to_multiple(pos, 4);
            let req_len = round_up_to_multiple(len, 4).max(MINIMUM_READ_LENGTH);

( Rounding down / up to nearest 4-byre alignment? )

Looking at those two rounding functions, it appears they behave a bit different when n % m == 0.
Rounding down 12 by multiples of 4 yields 12, as expected.
Rounding up 12 by multiples of 4 yields to 16, not 12, as I would expect. was this intentional?
Also these functions seem perfect candidates for #[inline], as they are very small and do not really warrant a function call I think?

Thanks in advance for your thoughts!
~ Luuk

Played around on the playground:

Round down n: 11 to multiples of m: 4 gives: 8
Round down n: 12 to multiples of m: 4 gives: 12
Round down n: 13 to multiples of m: 4 gives: 12
current round-up
Round up n: 11 to multiples of m: 4 gives: 12
Round up n: 12 to multiples of m: 4 gives: 16
Round up n: 13 to multiples of m: 4 gives: 16

Alternative round-up (symmetric to round down):
Round up n: 11 to multiples of m: 4 gives: 12
Round up n: 12 to multiples of m: 4 gives: 12
Round up n: 13 to multiples of m: 4 gives: 16

[jpochyla]

Hi @luukvanderduim, thanks for looking into Psst's code-base!

Honestly, I think we could remove the functions entirely, as there's no 4-byte-alignment requirement now for the chunk-fetching mechanism (unlike before).

Also these functions seem perfect candidates for #[inline], as they are very small and do not really warrant a function call I think?

#[inline] matters only when inlining across crates, which is not the case here.

[luukvanderduim]

Honestly, I think we could remove the functions entirely, as there's no 4-byte-alignment requirement now for the chunk-fetching mechanism (unlike before).

Removing code is extra satisfying! ;)

Also these functions seem perfect candidates for #[inline], as they are very small and do not really warrant a function call I think?

#[inline] matters only when inlining across crates, which is not the case here.

You are right, there is no need to #[inline] here. The compiler can decide itself if it needs to inline private functions. From what I've read, LLVM is quite an eager inliner.

For those interested @matklad wrote an excellent blog post on inlining.