PERF: Using _Period for optimization
State: closed

- [ ] closes #xxxx
- [ ] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

---
I did two bench marks one in a tight loop(```%timeit```), and one with asv.

I don't see a significant performance change (but I'm not sure I read the output correctly), maybe worth just removing the "TODO" note.

---

#### Benchmarks:

##### Timeit:

```
In [1]: import pandas as pd                                                                                   

In [2]: idx = pd.period_range("2000-01-01", periods=3)                                                        

In [3]: %timeit idx.get_loc(idx[1], "pad") 
337 µs ± 15 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) # Master
338 µs ± 7.16 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) # PR
```

##### ASV (period.Indexing)

```
       before           after         ratio
     [f20331d5]       [f71bf172]
     <master>         <PERF-index-_Period>
      1.46±0.02ms      1.45±0.03ms     0.99  period.Indexing.time_align
       8.57±0.2μs       8.51±0.2μs     0.99  period.Indexing.time_get_loc
         512±30μs          506±3μs     0.99  period.Indexing.time_intersection
         30.6±2μs       30.8±0.3μs     1.01  period.Indexing.time_series_loc
       3.95±0.3μs      3.96±0.02μs     1.00  period.Indexing.time_shallow_copy
       87.9±0.5μs       88.5±0.6μs     1.01  period.Indexing.time_unique
```

Labels:
name: Performance
description: Memory or execution speed performance
name: Period
description: Period data type

Comments:
ASV benchmarks:

```
All benchmarks:

       before           after         ratio
     [2ef8fd1b]       [5f7a6ebc]
     <master>         <PERF-index-_Period>
      1.53±0.03ms      1.47±0.02ms     0.97  period.Indexing.time_align
       8.72±0.2μs      8.40±0.06μs     0.96  period.Indexing.time_get_loc
         545±20μs         502±10μs     0.92  period.Indexing.time_intersection
       31.5±0.7μs         32.3±2μs     1.03  period.Indexing.time_series_loc
       4.19±0.2μs      4.15±0.05μs     0.99  period.Indexing.time_shallow_copy
         93.6±4μs       88.5±0.3μs     0.95  period.Indexing.time_unique
```
ok so not much improvements. @jbrockmendel 
@MomIsBestFriend since the improvements are very small, two questions to ask:

1) are those asv results accurate/precise?  i.e. are they consistent across runs?  `get_loc` is them only one id really expect to be affected
2) is the build size or affected?
>     1. are those asv results accurate/precise?  i.e. are they consistent across runs?  `get_loc` is them only one id really expect to be affected

Yes the ```asv``` results are in fact consistent across runs, I have ran the ```period.Indexing.time_get_loc``` benchmark 5 times and it the results range is between ```8.00 - 9.00``` ```μs``` (for both```master``` and this PR.

>     2. is the build size or affected?

@jbrockmendel What do you mean by "build size"?
> and it the results range is between 8.00 - 9.00 μs (for bothmaster and this PR.

Are the "ratio" numbers consistent?  I'm looking to be able to make a concrete statement to the effect of "this makes a small but non-zero improvement in X"

> What do you mean by "build size"?

Roughly i mean the size in bytes of the wheel we end up distributing.  Could alternatively measure the memory footprint of the imported modules, but thats trickier.

Not strongly against this, but a slight preference to just remove the TODO; this doesn't seem to have a material impact so I don't think worth any added complexity
> > and it the results range is between 8.00 - 9.00 μs (for bothmaster and this PR.
> 
> Are the "ratio" numbers consistent? I'm looking to be able to make a concrete statement to the effect of "this makes a small but non-zero improvement in X"

Yes the numbers are consistent, unfortunately you can't say that there is an improvement. 
> > What do you mean by "build size"?
> 
> Roughly i mean the size in bytes of the wheel we end up distributing.  Could alternatively measure the memory footprint of the imported modules, but thats trickier.

There is a size difference which is only a 4 bytes (PR is smaller)





>  remove the TODO; this doesn't seem to have a material impact so I don't think worth any added complexity

Agreed


> > remove the TODO; this doesn't seem to have a material impact so I don't think worth any added complexity
> 
> Agreed

agree here, @MomIsBestFriend if you can just remove the TODO and drop the other changes can accept this PR.
thanks @MomIsBestFriend