Added performance counters to zippers

[imlvts]

This introduces timed_span macros used in all the zipper methods.
The macro uses a global array for each span, incrementing times the span was entered, and platform-specific TSC delta spent in the span.
The counters may be either read from a static array, or printed using pathmap::timed_span::print_counters();.

[luketpeterson]

Hey. Sorry I didn't see this PR amid all the other churn.

High-level questions:

• Is this feature intended for internal use (optimizing pathmap) or external use (helping users optimize code that uses pathmap)?
• Is the cost negligible to have it always on? Or should be be behind a feature flag when it's not needed?
• Is it going to cause a problem that some zipper implementations provide their own implementations of some methods, and therefore won't call the default impls with the timed_span! macro invocations in them?

[Adam-Vandervorst]

Can we pull this at least into a non master branch @luketpeterson ?

[Adam-Vandervorst]

Bump @luketpeterson

[luketpeterson]

I have no problem main-lining this, but if it's targeted towards internal optimization then it probably belongs behind a feature gate.

@imlvts, What are your opinions on these questions? #14 (comment)

[luketpeterson]

Just to clean house, it would be good to do something about this PR. There is useful work here.

My feeling is that there are two things here:

1. The timed_span! macro itself. Which is generally a pretty useful piece of functionality, but not really specific to the pathmap crate.
2. Using timed_span! in dozens of places across the implementations of ReadZipperCore and ACTZipper. Having this instrumentation in there to enable with a single feature might be handy. Another quick way to get a profile.

• If it were me, I'd make timed_span a stand-alone crate, and publish it separately to crates.io. There is already a crate called https://crates.io/crates/scopetime But IMO timed_span is better because the atomic table allows for finer-grained tracking than the logging the other crate uses* (and the scopetime crate hasn't been updated in 3+ years) @imlvts this is your work, so I would not publish it myself unless you asked me to. But I can (ask the clanker to) do it if you want.

• Once that crate is available to be used as a dependency, we could make an optional feature, e.g. zipper_timing to set up the timing_entries and then enable timed_span in a handful of places inside ReadZipperCore and ACTZipper.

*I don't know if the timer resolution makes the measurements unreliable. My Macbook has a 24Mhz timer so it only measures 41ns and a lot of zipper ops run faster than that when cache is hit. My guess is that this would shake out across millions of operations, and be a non-issue.