Thanks to visit codestin.com
Credit goes to github.com

Skip to content

MAINT: Import time: Avoid importing python.Threading #14098

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

hmaarrfk
Copy link
Contributor

See here:
#14083

Just testing on CIs for now.

@hmaarrfk hmaarrfk force-pushed the pythread_lock branch 2 times, most recently from 88a59d0 to 922cee9 Compare July 25, 2019 03:41
@hmaarrfk
Copy link
Contributor Author

@eric-wieser do you know why azure won't run on this? I'm pretty sure CPython will work, just not PyPy.

@seberg
Copy link
Member

seberg commented Jul 25, 2019

I think some heisenbug or so on windows came up a bit often on azure the last few PRs? (not quite sure though).

@hmaarrfk
Copy link
Contributor Author

Yeah, I think so too.

from cpython.pycapsule cimport PyCapsule_New

# Threading isn't the cheapest import. Import from the lightweight
# _thread module,
from _thread import allocate_lock as Lock
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that the _thread method might be choking the pypy test? (i.e. that lock waits forever?). How OK is it really to use the _thread name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The python STL was documenting it.

But I guess I misunderstood what they meant by low level.

https://docs.python.org/3/library/concurrency.html

I kinda knew I was doing a bad thing, so I didn't try it first. I think I might have to rerun initial benchmarks now that some of the other PRs are going through

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dunno, it seems that python might have started to endorse _thread specfically, and possibly pypy just has a bug.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to start rerunning these benchmarks again. Some of these fixes are related to deprecation cleanups. Others like this one are more hazy. One could argue that importing from _thread is obscure and shouldn't be done even if it was supported by both PyPy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

root@c766aae4e273:/# pypy3.6-v7.1.1-linux64/bin/pypy3 
Python 3.6.1 (784b254d6699, Apr 14 2019, 10:22:42)
[PyPy 7.1.1-beta0 with GCC 6.2.0 20160901] on linux
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``snow, snow''
>>>> import _thread
>>>> from _thread import allocate_lock as Lock
>>>> Lock
<built-in function allocate_lock>

This seems to work on the latest downloaded PyPy

@eric-wieser
Copy link
Member

How does this behave on systems whether threading is unavailable?

@hmaarrfk
Copy link
Contributor Author

Oh I guess that is what dummy threading was for. Not too sure for now. PyPy has threading right?

@seberg
Copy link
Member

seberg commented Jul 26, 2019

But you can compile python without threading. PyPy should fail the import if it had no threading, but it seems rather that it hangs on an infinite Lock somewhere.

@charris charris changed the title WIP: MNT: Import time: Avoid importing python.Threading WIP: MAINT: Import time: Avoid importing python.Threading Aug 8, 2019
@mattip
Copy link
Member

mattip commented Aug 15, 2019

I am not sure about this PR. It seems to increase code fragility for a minimal decrease in import time.

@hmaarrfk hmaarrfk changed the title WIP: MAINT: Import time: Avoid importing python.Threading MAINT: Import time: Avoid importing python.Threading Aug 17, 2019
@hmaarrfk
Copy link
Contributor Author

I think it might have a more measurable effect once #14097 gets pulled in. I was able to get down to 70 ms in my original omnibus PR. I can bechmark after that gets approved again.

@hmaarrfk
Copy link
Contributor Author

It might be difficult to see the results of this without getting rid of a shutil import in _datasource. shutil ends up importing many different compression formats trying to see if they are installed in a pythonic way at import time.

Unfortunately, bz2 imports Threading just for RLock. I think a PR can be made upstream to use the lightweight _thread module there too.
https://github.com/python/cpython/blob/master/Lib/bz2.py#L17

@hmaarrfk
Copy link
Contributor Author

I'm not sure upstream will accept using _thread.RLock as they specifically created a workaround for it.

https://github.com/python/cpython/blob/master/Lib/threading.py#L95

That said, even pypy has RLock implemented in C, so maybe :/.

It might be more fruitful to fix upstream. They don't seem to have a c implementation of excepthook which is causing traceback to be imported when the threading module is imported.
https://github.com/python/cpython/blob/master/Lib/threading.py#L1128

@hmaarrfk hmaarrfk closed this Aug 25, 2019
@hmaarrfk
Copy link
Contributor Author

FYI, it seems that the above comment is under development, and might actually be fixed in python 3.8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants