+1, I would also like this

I tried doing this when scalene was first announced
master...chiragjn:contextmanager_patch
Since scalene does line by line output. it would either output too much code or crash with ipython cells (because they are not files).

My fork is also out of date by now, I might sync up and give it another shot if I get some time

So, did this patch work? It doesn't look like it would take much effort to resolve the conflicts (I can do this, just let me know).

@emeryberger Since this hasn't been updated, and I would like to have a context manager for my project, I would like to pick this one up.

Sounds great! I look forward to a PR. Let me know if you have any questions, etc.

It seems to be harder than I initially thought. Would you be willing to call some time so we can discuss a good approach to solve this?

Sure. Drop me a line: emery.berger@gmail.com.

I do think that it doesn't make sense to disable a lot of the functionality; in effect, it seems like the contextmanager approach should just be a way to say "just give me the results from this function"; that maybe is most expediently handled in the should_trace method, and then with some additional logic in the profile output routine.

was there any progress on this? one reason for wanting it is to leave out startup overhead from the profile (ie. if I know that the startup overhead is paid only once or not in the perf-intensive part of my code)

It would be straightforward to have a command-line parameter for a start profile delay, but I am not clear how much it would matter for any sufficiently long running program, which would eventually amortize the startup cost. But if it’s a real need, it would be easy to add.

sorry I wasn't clear earlier. I meant that in my program, there is an expensive data loading step at the beginning that needs to be executed once, and then a loop over less expensive steps. I want to profile the less expensive step. I'd like to skip profiling the data loading step.

So would it be practical to time the expensive data loading part, and then have Scalene start its profiling after that much time has elapsed?

Yes, that is certainly one approach, but the approach suggested in this issue (a context manager or other way of turning profiling on and off programmatically instead of at the command line) would be my preference - seems cleaner and more flexible.

From an implementation perspective, it's challenging. Scalene (when it's not invoked with --cpu-only) uses a library that replaces all memory operations (allocations, frees, and copying). It's not something you can safely turn and off. What I would actually have to do is profile all the time, but simply discard profiling information when profiling is "off". Since even this would require refactoring and special casing (what happens with multiple processes, for example?), I'd really like to see a compelling case that isn't handled by something much simpler, like delaying the start of profiling.

UPDATE: As of version 1.1.5, Scalene now supports @profile decorators.