Re: Benchmark diamond operator

The <> diamond operator, acting upon @ARGV is going to be tricky to get right, if you want to re-read the same file multiple times to benchmark. Better off using open to manually act upon the filenames passed into @ARGV. That way you can re-open for each run, or (probably faster), open once, tell, and seek to reset between iterations.

There are faster alternatives than <>, but if your drive is a mechanical drive, shifting over to SSD is the biggest win.

Dave

Comment on Re: Benchmark diamond operator Select or Download Code

Replies are listed 'Best First'.
Re^2: Benchmark diamond operator by thanos1983 (Parson) on May 09, 2017 at 14:59 UTC
Hello davido, Alternatives than `<>` that are faster? Can you propose some so I could use them as future reference? Thank you for your time and effort. Seeking for Perl wisdom...on the process of learning...not there...yet!	[reply] [d/l] [select]
Re^3: Benchmark diamond operator by davido (Cardinal) on May 10, 2017 at 15:56 UTC
`<>` is a general purpose tool, and as such is optimized for "the general case." There isn't one single tool that can optimize for speed across the general case (or in other words, the majority of all use cases). If you know your data-set well, you can optimize by selecting a less general tool to fit your specific need. Tools to consider include: read: May be faster for small reads. sysread: May be faster for large reads. Sys::Mmap and File::Map: May be faster for large files in some specific cases. Lower-impact layers (eg `:raw` or `:mmap`) may offer speed advantages in some cases while reducing functionality in other areas. Each of these methods come with caveats, pitfalls, limitations, and unique benefits. It is up to you to decide if the limitations are outweighed by the benefits for your specific use case. benchmarking is the only way you'll be sure that one is a win over the other for your specific situation. Dave	[reply] [d/l] [select]