`log_sparse=True` doesn't work with context manager about viztracer

[gaogaotiantian]

Also I'll review the code when I got some time :)

[gaogaotiantian]

I'm curious about the actual usage for this. Is there a reason that you can't or won't use the command line tool? Do you need to switch between log_sparse mode and the normal mode frequently when you profile your program?

log_sparse mode is basically turning off the tracer, which makes the VizTracer context weird - it really doesn't do anything except for creating a new instance.

There's an actual concern here though - currently we promise @log_sparse decorator introduces no run-time overhead (of course when calling, not decorating) if there's no tracer. This is a very good feature as the users would be comfortable leaving the decorator as it is, even for production code. By introducing run-time check for the tracer, we break that promise, which may counteract the fact that we are slightly more flexible when using the feature.

[AlexeyKozhevin]

I would like to use your library for benchmarking ML pipelines, for example, written with batchflow.
Most of the work is done inside jupyter notebook so it's not very convenient to move pipelines to scripts at R&D stage but profiling is necessary.

I find log_sparse extremely useful to profile pipelines like that

my_dataset.pipeline()
              .load('/some/path')
              .do_something(use_lock=True)
              .do_something_else()

The pipeline is launched by a separate executor with a large number of service calls so VizTracer with log_sparse=False produces statistics also for that calls.

At the same time, only the total execution time of individual actions that can be run in parallel in threads for individual batches is of interest. Therefore, decorating the executable action helped a lot to make such timeline

[gaogaotiantian]

Do you have any chance to run some code before your decorator takes effect? If you can do tracer = VizTracer() before decorating, it should be registered globally and the decorator should be able to pick it up and do what you want. This would be a better workaround than making it always check in run-time.

[AlexeyKozhevin]

This is a more likely option, but I will have to place initialization before all imports, because the decorated methods may be in other modules.

Maybe it's worth making another decorator that will check at runtime only the first time the decorated function is called?

[gaogaotiantian]

Yeah that's an acceptable solutiion. We can add an optional argument dynamic_tracer_check=False to the decorator itself which can be set to True to force the returned function to check whether trace exists every time the function is called. This change requires docs change, I can work on it, or if you are willing to do it yourself, you are more than welcome.

[AlexeyKozhevin]

Yeap, I can do it

[AlexeyKozhevin]

I've add dynamic_tracer_check and started to test. Everything is okay with threads but I found that the context manager cannot work with multiprocessing. You have all necessary workarounds (like install_all_hooks) but they are located in VizUI/run_code.

What do you think is the most appropriate way to reuse all of this? Move to Viztracer class or create new class (some kind of executor)?

[gaogaotiantian]

multiprocessing only works with the command line interface at this point, that's another topic (not related to `log_sparse).

It's more than the hooks, it's about install hooks before multiprocessing starts working and collect data (wait for other processes). The current code is delicate and I'm not confident to make inline tracer work without breaking something.

As of now, that behavior would probably keep the way it is. All the monkey-patching methods normally have some extra requirements. So no multiprocessing support for inline tracer, only CLI at this time.

[AlexeyKozhevin]

I took into account your comments, made changes and also added some tests. Thanks to them, I found a situation to fix.
I will update the PR soon.