This will conflict with https://github.com/matplotlib/matplotlib/pull/16617/files#diff-506c6bd01694bddbd8999f2c6e920705. Feel free to pick up the relevant patch in my PR, or I can rebase mine on top of yours, whatever works for you.

@anntzer mine is a very local change, so I'm ok with waiting until yours lands.

Either way is fine, but I think you should check whether manually constructing the codes array is significantly faster than using codes=True -- and, if so, leave a comment explicitly asking that the codepath not be "simplified" to codes=True later.

@anntzer I assume you meant closed=True, right? In this case, yes, creating the codes once is much faster (about 400ms in my benchmark likely due to smaller GC pressure, fewer allocations, etc.).

@timhoffm Added the test.

@anntzer I've changed the slow path to use closed=True now, but I'm wondering if it wouldn't still be faster to use a dict to memoize codes for each length. I don't care that much about the unoptimized path in my solution though, but I can benchmark it if you want.

I guess that could actually be a useful general optimization in path.py? e.g. preallocate the codes for closed paths of up to, say, 16 vertices (I picked 16 because that's the same threshold for caching as in unit_regular_polygon/unit_regular_star).

(In which case perhaps implement that optimization first and see whether you can exploit it here.)

@anntzer Good point. I'll experiment with that once this lands.

It would be great if this could get another stamp and land. I've done some more work and it turns out that path creation can be optimized even further! After this PR it takes ~1.4s to create all the paths, but a ~20 LOC change allows to bring this down to ~0.19s. A more hacky version gets this even lower (to ~0.1s), but that is a bit too much for my taste (it requires inlining some function bodies — calls are expensive in Python).

With the PRs I've submitted so far (including this one), the rendering for my example (400x400 surface plot on a 2012 MBP) is ~2s on average. With the changes I have stacked on top of this it drops to ~0.7s. The breakdown of this 0.7s is:

• ~0.4s in Poly3DCollection.do_3d_projection
  • Including ~0.2s in Collection.set_paths
• ~0.3s in Collection.draw (mostly spend in the C code for the Agg backend in this case)

I've also done a bit more digging and I think it would be feasible to refactor Collection such that it will always store the data of _paths in a NumPy array (possibly masked). That should eliminate a lot of overhead, both for the do_3d_projection part, as well as the backend.

Anyone can merge after CI passes (ignoring circleci, which shouldn't be affected by this and is getting fixed (hopefully) in #16784.)

Not sure what causes the matplotlib.matplotlib Windows failures. OS X and Linux jobs are green and I can't reproduce it locally either. Is that a known issue?

that just looks like flakiness. do you want to squash the last commit? either way is fine.

All commits are now squashed.

thanks :)

@anntzer Thanks for all the reviews and help with getting this code in!

You're welcome; your PRs are great 😁