speed up generic polynomials

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​7bb0dc8

optimize generic polynomial coefficient access

[tscrim]

I know this is close to bikeshedding, but I think a slightly more descriptive name would be more appropriate, such as get_coeff or get_coeff_c, would be better in the long-term for code readability.

Have you also run some timings?

I will also push some further changes that are micro-optimizations (mostly avoiding extra calls to degree() by using get_unsafe() because we have already checked the degree is non-negative).

[mmezzarobba]

Replying to tscrim:

I know this is close to bikeshedding, but I think a slightly more descriptive name would be more appropriate, such as get_coeff or get_coeff_c, would be better in the long-term for code readability.

Fine with me.

Have you also run some timings?

No micro-benchmarks, but this change seems to speed up the “real-world” code I was profiling by ~3%.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​31be202

optimize generic polynomial coefficient access

[tscrim]

I chose get_coeff_c to be more explicit that it is a C-level method and so that there would be less chances of accidental conflicts with subclasses.

All of the other changes I did should be micro-optimizations as they avoid checks, multiple calls to other functions (e.g., degree()), have more direct paths. I didn't do every possible place because I felt the code clarity outweighed a (very) micro speed gain. Unfortunately there were a few places where having the field with 1 element made it so we had to have different cases (the unit code in particular).

Marc, could you run your "real-world" example again against the code on your branch to see if you notice any differences?

---

New commits:

​1922631

get_fast -> get_coeff_c and some micro-optimizations.

[mmezzarobba]

Replying to tscrim:

Marc, could you run your "real-world" example again against the code on your branch to see if you notice any differences?

It seems again a bit (2%?) faster. (Of course, that may be measurement error--perhaps even more than with my first commit, which was motivated by __getitem__() showing up in the profiler output!)

[tscrim]

Replying to mmezzarobba:

Replying to tscrim:

Marc, could you run your "real-world" example again against the code on your branch to see if you notice any differences?

It seems again a bit (2%?) faster. (Of course, that may be measurement error--perhaps even more than with my first commit, which was motivated by __getitem__() showing up in the profiler output!)

Thank you for running it. That is about what I was generically expecting given my changes (not clearly significant, but a noticeable improvement).

So if my changes are good, feel free to set a positive review. Thank you for your work.

[mmezzarobba]

Thank you!