Improve performance on pointer drop

[davidhewitt]

There's a Mutex involved each time we drop a PyObject or Py<T>, so that we can safely push the reference into the shared Vec. I have been wondering for a while if we could add a simple check if the GIL is held (as a thread_local! variable) and if so, decrease the refcount immediately.

I tried this out - turns out in the simple benchmark I made (bench_object) that adding this check makes the benchmark 5x faster.

I think decreasing the reference count sooner is also more predictable from a pyo3 user perspective. It helps with some of the issues around #311. (Though this doesn't improve the situation for references.)

If the GIL is not held, then I made it so that the pointers will be released as soon as the GIL is next acquired.

To track when the GIL is held I have added counters to GILGuard::new() and GILGuard:drop().

For this optimization to apply all the time we also need to increment / decrement this counter when we call assume_gil_acquired() - which suggests to me that we should wait to finish this off once #800 is solved.

TODO:

• Also increment / decrement GIL_COUNT when we call assume_gil_acquired() (solved by also using GILPool for the counter)

[kngwyu]

Why do we need to release pointers here?
To reduce memory usage?

[davidhewitt]

Two reasons:

1. Yes, memory usage - we're now releasing the pointers sooner
2. This (Why object creation is slow in PyO3 and how to enhance it #679 (comment)) suggested to me that it's important in the long run we migrate to releasing objects on GIL acquire, not GIL exit.

[kngwyu]

Ah, I understand. Thank you for the reference.

[kngwyu]

Great, thanks!

For this optimization to apply all the time we also need to increment / decrement this counter when we call assume_gil_acquired()

I'm not sure how the next assume_gil_acquired API would be so I think it's sufficient if GILPool increments/decrements the counter for now.

[davidhewitt]

Good idea. I now use both GILGuard and GILPool for the counter, which should cover all use cases.

[davidhewitt]

Formatting error again 🤦 I'll fix later

[davidhewitt]

Re-pushed with fixed formatting; should be green in CI now I hope.

[kngwyu]

Thank you!