Skip to content
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

Autoprofile is not working as expected. #318

Open
Erotemic opened this issue Feb 8, 2025 · 2 comments
Open

Autoprofile is not working as expected. #318

Erotemic opened this issue Feb 8, 2025 · 2 comments

Comments

@Erotemic
Copy link
Member

Erotemic commented Feb 8, 2025

@ta946 I'm running into an issue when attempting to use autoprofiling.

Maybe I'm remember how to use it wrong, but if I am, there is something unintuitive about the design we came up with that we might want to address in either the docs or in code changes.

The goal is that I'd like to autoprofile an entire package when running a command line tool. Unfortunately kernprof can't run a python module (e.g. python -m modname), it has to run a script (e.g. python modname.py), which makes this annoying. Ideally if I wanted to profile pip, I could do something like: python -m kernprof -l --prof-mod pip -m pip, but that's a separate issue and we can work around it by writing a script that calls the module main function of interest:

echo "
from pip._internal.cli.main import main as _main
_main()
" > my_script_v1.py
chmod +x my_script_v1.py


python -m kernprof -l \
    --prof-mod pip \
    ./my_script_v1.py freeze

python -m line_profiler -rmt "my_script_v1.py.lprof"

Now, I would expect that because we are asking it to profile a package directory that all functions and imports in pip itself would be decorated, but that doesn't seem to be the case. They are recognized, but there seems to be a rule that filters them out.

However, if I explicitly import some of the modules beforehand, I will end up profiling their contents:

echo "
from pip._internal.cli.main import main as _main
import pip._vendor
import pip._internal.utils.hashes
_main()
" > my_script_v2.py
chmod +x my_script_v2.py


python -m kernprof -l \
    --prof-mod pip \
    ./my_script_v2.py freeze

python -m line_profiler -rmt "my_script_v2.py.lprof"

Thinking about this: maybe the problem is that the modules aren't loaded when the AST transformer does its decorations? We probably don't want to do anything that would force a different import order than would happen when running the program naturally, but maybe there is a way to hook into the import system and decorate any module that is within the requested package and imported after profiling starts?

@Erotemic
Copy link
Member Author

Erotemic commented Feb 8, 2025

Also noting that when it does autoprofile it seems to miss setter and getter properties

@ta946
Copy link

ta946 commented Feb 9, 2025

ok just looked into whats happening. this was more of a design decision we made previously..

When you add pip to prof_mod, it finds pip._vendor and pip._internal.utils.hashes, as well as 350+ other submodule files, so autoprofile is aware of them. But to profile them, you would need to have them imported so that line profiler can decorate it

But since they are hidden from the main script, we chose to not profile them since it would mean trying to profile everything recursively (which might require importing those subomdules into the top of the AST then wrapping in profile(submodule)), so we decided you would have to explicitly enter which submodules you want profiled

Not sure what the best approach is here..
in an ideal world i would follow the _main() submodule and find the imports in there, but that would require opening the file and repeating the same process we do for the main script, and it might need to be done recursively for every import

As for the setter & getter, never needed to profile so never tested it.. would be good to have a test case we can play around with

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

No branches or pull requests

2 participants