You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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:
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:
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?
The text was updated successfully, but these errors were encountered:
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
@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: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:
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?
The text was updated successfully, but these errors were encountered: