[ptr_arg] writing `&Vec<_>` instead of `&[_]` has a important performance impact (~20%)

Summary

Hello !

I've noticed that Clippy suggest me to change a &Vec<Vec<u8>> into &[Vec<u8>] but performances are worse

Here my function :

fn get_pixel(i: i32, j: i32, image: &Vec<Vec<u8>>, infinite_value: usize) -> usize {
   ...
}

my function get_pixel is called a lot, here a summary :

fn calcul_pixel_sorti( ... image: &Vec<Vec<u8>> ... ) -> u8 {
...  
  for ...
    for ...
      get_pixel(i, j, image, infinite_value);
...
}

The clippy message

warning: writing `&Vec<_>` instead of `&[_]` involves one more reference and cannot be used with non-Vec-based slices
  --> src/day20/src/lib.rs:99:37
   |
99 | fn get_pixel(i: i32, j: i32, image: &Vec<Vec<u8>>, infinite_value: usize) -> usize {
   |                                     ^^^^^^^^^^^^^ help: change this to: `&[Vec<u8>]`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg

If i use this function signature :

fn get_pixel(i: i32, j: i32, image: &Vec<Vec<u8>>, infinite_value: usize) -> usize {

, the full computation take : 8,12 ms

but if i follow the clippy recommandation, with this signature :

fn get_pixel(i: i32, j: i32, image: &[Vec<u8>], infinite_value: usize) -> usize {

it take 9,68ms
So i think Clippy shouldn't recommend this kind of checks, because 19% slower is bad from my point of view :(

Lint Name

ptr_arg

Reproducer

I've attached an example to run, (it's the resolution of day 20 in advent-of-code ;-) )

The line to change is in src/day20/src/lib.rs, line 100, informations are described in the Readme.md

clippy_ptr_arg.zip

Version

rustc 1.60.0-nightly (17d29dcdc 2022-01-21)
binary: rustc
commit-hash: 17d29dcdce9b9e838635eb0adefd9b8b1588410b
commit-date: 2022-01-21
host: x86_64-unknown-linux-gnu
release: 1.60.0-nightly
LLVM version: 13.0.0

Additional Labels

No response

Start by running the attached clippy_ptr_arg.zip reproducer and compare the two get_pixel signatures in src/day20/src/lib.rs around line 100, using the README for the described setup. Then trace the ptr_arg lint behavior and verify whether the reported performance difference is reproducible; done means the lint no longer causes the reported regression or the behavior is documented with evidence.