PERF: use uniqueness_check from monotonic check when possible
State: closed

closes #14266


Labels:
name: Indexing
description: Related to indexing on series/frames, not to indexes themselves
name: Performance
description: Memory or execution speed performance

Comments:
@ssanderson @llllllllll 

can you give this a check (ideally you can perf test this as well)......

Is this big enough to warrant a second release candidate? (you have a better understanding for how big a change this is).

@TomAugspurger well our entire test suite passes, so I don't think this is a big deal as not changing  functionaility (this is almost a bug fix).

some nice perf improvements as well (note these are backwards, in that a7469rc9 is master)

```
  [9ced5d50] [a7469cf9]
+   14.98μs    54.75ms   3656.26  indexing.series_getitem_scalar.time_series_getitem_scalar
+   30.83μs    54.60ms   1770.70  indexing.series_ix_scalar.time_series_ix_scalar
+   50.48μs    52.97ms   1049.33  indexing.series_loc_slice.time_series_loc_slice
+   54.64μs    53.11ms    972.14  indexing.series_ix_slice.time_series_ix_slice
+    2.21ms    56.38ms     25.52  timeseries.timeseries_large_lookup_value.time_timeseries_large_lookup_value
+    1.36ms     4.17ms      3.08  timeseries.timeseries_datetimeindex_offset_delta.time_timeseries_datetimeindex_offset_delta
+  231.80μs   514.32μs      2.22  timeseries.datetimeindex_add_offset.time_datetimeindex_add_offset
-    3.45ms     1.50ms      0.43  index_object.index_datetime_set_difference.time_index_datetime_difference_disjoint
-   51.35ms    21.71ms      0.42  frame_methods.frame_getitem_single_column.time_frame_getitem_single_column
-  312.45μs   129.48μs      0.41  timeseries.timeseries_asof_single.time_timeseries_asof_single
-  239.91μs    92.65μs      0.39  index_object.datetime_index_union.time_datetime_index_union
SOME BENCHMARKS HAVE CHANGED SIGNIFICANTLY.
```

@ssanderson if you could test out would be great.

## [Current coverage](https://codecov.io/gh/pydata/pandas/pull/14270?src=pr) is 85.25% (diff: 100%)

> Merging [#14270](https://codecov.io/gh/pydata/pandas/pull/14270?src=pr) into [master](https://codecov.io/gh/pydata/pandas/branch/master?src=pr) will decrease coverage by **<.01%**

``` diff
@@             master     #14270   diff @@
==========================================
  Files           140        140          
  Lines         50568      50568          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          43112      43111     -1   
- Misses         7456       7457     +1   
  Partials          0          0          
```

> Powered by [Codecov](https://codecov.io?src=pr). Last update [a7469cf...968a4f7](https://codecov.io/gh/pydata/pandas/compare/a7469cf98275a183ad2e4bfafa9706a1ef8d035e...968a4f7b2a507276f13f886596121844262afcca?src=pr)

@jreback I'll take a look shortly.

This change looks good to me, not sure if I can easily test zipline with this though. Running the memory usage example from the issue shows the memory usage pretty constant across the get_loc call. Thanks for the really quick fix!

I'm installing this into a fresh zipline build to see if it runs (there may
be upgrade work that needs to happen to be compat with 0.19, so if that
doesn't work I'll probably just confirm the minimal repro case as well.)

On Wed, Sep 21, 2016 at 1:55 PM, Joe Jevnik notifications@github.com
wrote:

> This change looks good to me, not sure if I can easily test zipline with
> this though. Running the memory usage example from the issue shows the
> memory usage pretty constant across the get_loc call. Thanks for the really
> quick fix!
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> https://github.com/pydata/pandas/pull/14270#issuecomment-248691100, or mute
> the thread
> https://github.com/notifications/unsubscribe-auth/ABg8hf0Wb0pogI1wR6RgrZFbCKUhloBPks5qsW-IgaJpZM4KCxuk
> .

LGTM.  Thanks for the quick turnaround @jreback.