Tslibs resolution
One more step towards getting `tseries.frequencies` into cython (and getting rid of non-cython dependencies of tslib/period).  Also moves towards de-coupling period from tslib.

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

@jbrockmendel : I presume this is largely copy+paste?  Also, a quick `asv` check might be good just to make sure that nothing slowed down. >I presume this is largely copy+paste? 

Yes.

>Also, a quick asv check might be good just to make sure that nothing slowed down.

Will do. # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=h1) Report
> Merging [#18034](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/9e3ad63cdb030c6b369d9d822469bb968e2d1804?src=pr&el=desc) will **decrease** coverage by `0.07%`.
> The diff coverage is `76.92%`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/18034/graphs/tree.svg?token=eZ4WkYLtcO&src=pr&height=150&width=650)](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master   #18034      +/-   ##
==========================================
- Coverage   91.43%   91.36%   -0.08%     
==========================================
  Files         164      164              
  Lines       50090    49869     -221     
==========================================
- Hits        45798    45561     -237     
- Misses       4292     4308      +16
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `89.16% <76.92%> (-0.07%)` | :arrow_down: |
| #single | `40.23% <53.84%> (-0.2%)` | :arrow_down: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/tseries/frequencies.py](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree#diff-cGFuZGFzL3RzZXJpZXMvZnJlcXVlbmNpZXMucHk=) | `94.09% <100%> (-1.93%)` | :arrow_down: |
| [pandas/core/indexes/period.py](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9wZXJpb2QucHk=) | `92.9% <60%> (+0.01%)` | :arrow_up: |
| [pandas/plotting/\_converter.py](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree#diff-cGFuZGFzL3Bsb3R0aW5nL19jb252ZXJ0ZXIucHk=) | `63.44% <66.66%> (-1.77%)` | :arrow_down: |
| [pandas/io/gbq.py](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree#diff-cGFuZGFzL2lvL2dicS5weQ==) | `25% <0%> (-58.34%)` | :arrow_down: |
| [pandas/core/frame.py](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvZnJhbWUucHk=) | `97.8% <0%> (-0.1%)` | :arrow_down: |
| [pandas/core/indexes/datetimes.py](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9kYXRldGltZXMucHk=) | `95.48% <0%> (+0.09%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=footer). Last update [9e3ad63...7b374d3](https://codecov.io/gh/pandas-dev/pandas/pull/18034?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 ```
taskset 3 asv continuous -f 1.1 -E virtualenv master HEAD -b timeseries
[...]
       before           after         ratio
     [6a945180]       [4b6080da]
+     42.3±0.07μs       47.1±0.3μs     1.12  timeseries.SemiMonthOffset.time_begin_apply
+        5.75±0μs      6.41±0.01μs     1.11  timeseries.DatetimeIndex.time_timestamp_tzinfo_cons
-        1.10±0ms          997±1μs     0.91  timeseries.ResampleSeries.time_1min_5min_mean
-     20.7±0.05μs      18.7±0.05μs     0.90  timeseries.Offsets.time_custom_bday_apply_dt64
-         153±3μs        133±0.5μs     0.87  timeseries.Offsets.time_custom_bmonthbegin_decr_n
-      33.9±0.3μs       28.6±0.1μs     0.84  timeseries.Offsets.time_custom_bday_cal_decr
-      6.15±0.5ms      5.19±0.01ms     0.84  timeseries.DatetimeIndex.time_infer_freq_daily
-        14.7±1ms         11.9±0ms     0.81  timeseries.DatetimeIndex.time_infer_freq_none
-     18.7±0.04μs      14.6±0.04μs     0.78  timeseries.Offsets.time_custom_bday_apply
-      16.3±0.8ms      10.6±0.04ms     0.65  timeseries.AsOfDataFrame.time_asof_single
-           140ms         40.4±1ms     0.29  timeseries.DatetimeIndex.time_dti_factorize
-         159±5ms         37.0±3ms     0.23  timeseries.DatetimeIndex.time_dti_tz_factorize
-           1.96s          270±7ms     0.14  timeseries.AsOfDataFrame.time_asof_nan
-           1.95s          265±4ms     0.14  timeseries.AsOfDataFrame.time_asof
``` your benchmarks look odd > your benchmarks look odd

No argument there.  I'll rebase and re-run. ```
taskset 8 asv continuous -f 1.1 -E virtualenv master HEAD -b timeseries
[...]
       before           after         ratio
     [4578a039]       [58ced564]
+      28.4±0.1μs       32.1±0.9μs     1.13  timeseries.Offsets.time_custom_bday_cal_incr_neg_n
+           132ms            148ms     1.12  timeseries.DatetimeIndex.time_dti_factorize
-       152±0.6μs        137±0.8μs     0.90  timeseries.Offsets.time_custom_bmonthend_incr
-     22.3±0.08μs      19.8±0.07μs     0.89  timeseries.Offsets.time_custom_bday_incr
-      18.9±0.1μs       16.0±0.1μs     0.85  timeseries.AsOf.time_asof_single_early
-           2.00s         424±40ms     0.21  timeseries.AsOfDataFrame.time_asof
-           2.02s          422±7ms     0.21  timeseries.AsOfDataFrame.time_asof_nan

``` Clipboard again, is there a game plan for this error? rebase Hello @jbrockmendel! Thanks for updating the PR.















Cheers ! There are no PEP8 issues in this Pull Request. :beers: 

##### Comment last updated on November 13, 2017 at 00:01 Hours UTC rebase If we want to finish the day with a win, this and #18086 are probably about ready. rebase this I think next to go in. > I think next to go in.

Awesome.  I'll exercise some restraint and _not_ immediately replace. Travis failure is a timeout in TestClipboard.  I can only imagine the maintainers find this even more annoying than I do.  Still: argh > Travis failure is a timeout in TestClipboard. I can only imagine the maintainers find this even more annoying than I do. Still: argh

actually I merged a commit, which may fix this (but you rebase after). don't push again. let me review.
 ok ping on green. needs a rebase.  note that if you actually rebase on top of master (as opposed to merge master), then this becomes really simple to see where you are. you prob want to make a single commit when you do this as the conflicts are easier to resolve. or you can use an ide. It is *much* *much* easier to see what is going on w/o all of these constant merges. I would highly recommend you follow this workflow. since you rebase fairly frequently this is actually pretty easy to do. you don't actually need to squash (though again would recommend having logical commits). lgtm. ping on green. Ping thanks @jbrockmendel  > put a note - this is non performiant logic here (and duplicative) and this simply should call unique_1d directly
plus no reason to depend on khash directly;

Note: "here" refers to `tslibs.resolution.unique_deltas`.

So I tried using unique_1d directly and performance was hurt noticeably.  Not a huge shock since unique_1d is in py-land.  So as an experiment I took unique_1d, cut out a bunch of type-checking because the use case here is always a ndarray[int64_t], and implemented what was left directly in tslibs.resolution.  The surprise was that performance was still noticeably worse than under the status quo.

So is there a chance that this is performant logic here after all?