Feature: Profile multiple or all functions/classes?

[ChillarAnand]

Reloadium is a handy tool for profiling.

However, at the moment, it is profiling only the first function when the breakpoint is set.

When users want to switch/debug between functions, it becomes a hurdle to profile.

Also, if users want to profile the entire script, Reloadium can't do it at the moment.

Can we have the option to profile the entire script or select parts of a script?

[dkrystki]

I've tried making it work globally and unfortunately that slowed down the execution too much.
Collecting time for each line takes some time and that adds up producing misleading information.

As a compromise I'm thinking of collecting time for function call times globally and displaying that above function headers.
Additionally maybe a button "Collect line time information" to collect more data for a function of interest.

I'm open to other ideas how that could be implemented.

[ChillarAnand]

in addition to that child frames have to be traced by the debugger which is the biggest time penalty.

Just wondering why this will slow down ~15x.

The overhead of many other profilers in the python ecosystem is ~1.1x

[dkrystki]

15x slowdown comes from the debugger tracing function lines which is unfortunately slow.
Normally function lines are not traced unless there's a breakpoint inside but for line profiling that would have to be always enabled for all functions.

Other python profilers usually only measure function call times which is not as expensive as function lines.

[ChillarAnand]

I see.

Line profiler traces all the lines which are marked for profiling. But it never slows down as 15x.

Additionally maybe a button "Collect line time information" to collect more data for a function of interest.

A button or a decorator to mark the function that need to be profiled should also work fine.

[ChillarAnand]

Is it possible to disable the "hot reloading" option while doing profiling? Will it prevent a 15x slow down?

[dkrystki]

Hot reloading doesn't introduce significant slowdowns.
The majority of slowdowns come from python debugger tracing lines.
It does a lot of unnecessary for time profiling things (like watching for breakpoints etc).
I might add a more lightweight tracing function in the future to rectify this and enable deeper line profiling.