PERF: Using _Period for optimization

[ShaharNaveh]

• closes #xxxx
• tests added / passed
• passes black pandas
• 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

[jbrockmendel]

you would need to cimport _Period to get the performance improvement

[ShaharNaveh]

Just so I don't do anything stupid, I need to create the file period.pxd at pandas/_libs/tslibs/, correct?

[jbrockmendel]

yep

[ShaharNaveh]

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

[jreback]

ok so not much improvements. @jbrockmendel

[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?

[ShaharNaveh]

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 bothmaster and this PR.

2. is the build size or affected?

@jbrockmendel What do you mean by "build size"?

[jbrockmendel]

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.

[WillAyd]

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

[ShaharNaveh]

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)

[ShaharNaveh]

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

Agreed

[jreback]

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.

[jreback]

thanks @MomIsBestFriend