Provide a way to exclude some threads from the profile results

[GoogleCodeExporter]

Currently, I couldn't find a way to exclude some threads from the profile 
results. 

I.e.: When dealing with the PyDev debugger, there are some threads created just 
for the debugger, and I'd like to make those invisible to the profiler without 
making user-threads invisible too.

Original issue reported on code.google.com by fabi...@gmail.com on 21 Oct 2014 at 6:58

[GoogleCodeExporter]

Actually, that should be a feature request (couldn't find a way to change that 
now).

Original comment by fabi...@gmail.com on 21 Oct 2014 at 6:59

[GoogleCodeExporter]

We can add a filter function that yappi apply to threads when discovering them. 
If the user filter function return False, the thread will not be profiled.

Something like:

def exclude_pydev_threads(ident):
    thread = threading._active[ident]
    return not thread.name.startswith("PyDev...")

yappi.set_context_filter(exclude_pydev_threads)

Issue - calling back to python is risky.

Fabi, what do you think?

Original comment by nir...@gmail.com on 22 Oct 2014 at 8:53

[GoogleCodeExporter]

That'd be perfect for me...

Still, if calling back to Python is too risky, I could work with something as:

yappi.exclude_thread(thread_ident)

So, whenever I started a thread I'd check if yappi is available and if it is 
I'd call that function for the current thread (in the threads I want to 
ignore)...

There's an issue on whether a Thread is created during the profiling in this 
case (but for my use case it does work properly)

The pro is that I could make it work in my use-case and other people could make 
it work for their own use-cases (one without affecting the other -- as having 
only one callback could be an issue... although it could be circumvented by 
having yappi.add_context_filter instead of yappi.set_context_filter).

So, I guess you can decide what's easier for you to add -- any of those work 
for me :)

Original comment by fabi...@gmail.com on 22 Oct 2014 at 10:49

[GoogleCodeExporter]

An addition to nirsof's suggestion: 
The name can be add_context_filter(callback, type=["exclude", "include"])
and the filter also should be able to support "include", too, IMHO.

My opinion on calling back to Python:
Yes, calling back to Python is risky, however, if by default we won't call 
those, and if user explicitly wants to callback into Python, then that should 
be fine as we will document the risks around it and we are already doing that 
in other APIs like set_context_id_callback().

Original comment by sum...@gmail.com on 23 Oct 2014 at 10:18

[GoogleCodeExporter]

Let's wait the outcome of Issue 51 as if we can manage to have per-thread stat 
information, then we will not need these filtering function at all. User might 
be able to retrieve the thread's he/she is interested in.  

Original comment by sum...@gmail.com on 23 Oct 2014 at 7:45

[GoogleCodeExporter]

Closing this issue as we have implemented a way of retrieving per-thread 
function stats with issue51.

Original comment by sum...@gmail.com on 26 Nov 2014 at 1:28

[GoogleCodeExporter]

Original comment by sum...@gmail.com on 26 Nov 2014 at 1:29

• Changed state: Fixed