Double the performance of the archive parsing code

[nagisa]

Started at

  1,061.09 msec     task-clock:u              #    0.998 CPUs utilized
 3,374,141,510      cycles:u                  #    3.180 GHz
12,012,570,139      instructions:u            #    3.56  insn per cycle

after these commits we get

    580.57 msec     task-clock:u              #    0.997 CPUs utilized
 1,843,957,595      cycles:u                  #    3.176 GHz
 5,901,570,558      instructions:u            #    3.20  insn per cycle

A 54% of the original wall-clock runtime, executing slightly less than half the instructions.

The test case was is effectively just

diff --git a/examples/ar.rs b/examples/ar.rs
index 22c8553..064c9b1 100644
--- a/examples/ar.rs
+++ b/examples/ar.rs
@@ -34,13 +34,15 @@ fn main() {
             return;
         }
     };
-    match op.chars().next().unwrap() {
-        't' => {
-            for member in archive.members() {
-                let member = member.unwrap();
-                println!("{}", String::from_utf8_lossy(member.name()));
+
+    for _ in 0..1_000_000 {
+        match op.chars().next().unwrap() {
+            't' => {
+                for member in archive.members() {
+                    let member = member.unwrap();
+                }
             }
+            op => println!("Invalid operation: {}", op),
         }
-        op => println!("Invalid operation: {}", op),
     }
 }

memchr is a well regarded crate, used by the standard library core, so the concern over adding this dependency should be minimal, I hope.

See the commit descriptions for slightly more information.

[nagisa]

Now that I've done this, I'm thinking whether it wouldn't make sense to try and skip parsing of the filenames while just iterating through members in the first place.

[philipc]

Is there a use case where you want to iterate without getting the filename of every member? Parsing the names as we iterate is simpler (correct file size is known, and no need to pass the names buffer for parsing the filename later). Also, while I'm happy with this improvement, I'm unsure how relevant it is compared to the file read itself, which you weren't benchmarking.