-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation: Clarify filter function behaviors #43
Comments
Actually, I'm not even certain if that example is setting the module correctly at all. |
Ok. Let me clarify a bit. I think I can see where the confusion is coming from: the As an example: you can always do following: def foo():
pass
def bar():
pass
import yappi
yappi.start()
foo()
bar()
stats = yappi.get_func_stats()
for t in stats:
print(t)
'''
{0: 'bar', 1: 'x.py', 2: 5, 3: 1, 4: 1, 5: False, 6: 3e-06, 7: 3e-06, 8: 1, 9: <yappi.YChildFuncStats object at 0x10d67d1d0>, 10: 0, 11: '_MainThread', 12: 0, 13: 3e-06, 14: 'x.py:5 bar'}
{0: 'foo', 1: 'x.py', 2: 1, 3: 1, 4: 1, 5: False, 6: 3e-06, 7: 3e-06, 8: 0, 9: <yappi.YChildFuncStats object at 0x10d67d210>, 10: 0, 11: '_MainThread', 12: 0, 13: 3e-06, 14: 'x.py:1 foo'}
''' Here you can see the element keyed with 1 is the module's name which is: Let's see: for t in stats:
print(t.__dict__)
'''
{'name': 'foo', 'module': 'x.py', 'lineno': 1, 'ncall': 1, 'nactualcall': 1, 'builtin': False, 'ttot': 3e-06, 'tsub': 3e-06, 'index': 0, 'children': <yappi.YChildFuncStats object at 0x105a181d0>, 'ctx_id': 0, 'ctx_name': '_MainThread', 'tag': 0, 'tavg': 3e-06, 'full_name': 'x.py:1 foo'}
{'name': 'bar', 'module': 'x.py', 'lineno': 5, 'ncall': 1, 'nactualcall': 1, 'builtin': False, 'ttot': 2e-06, 'tsub': 2e-06, 'index': 1, 'children': <yappi.YChildFuncStats object at 0x105a18190>, 'ctx_id': 0, 'ctx_name': '_MainThread', 'tag': 0, 'tavg': 2e-06, 'full_name': 'x.py:5 bar'}
''' Now, it is better right? With this kind of introspection, I think any kind of filtering is possible easily? WDYT? The reason we have While discussing it, I feel that this also needs to be documented. I said docs are poor, right? :) Coming to your original question again:
I am not sure if I understand you correctly but say you filter on |
@sumerc This is definitely helpful. I'll play around with this more.
That is correct by what I meant as a "negative" filter. |
We have changed this whole filtering with the branch improve-filtering. All docs updated. Please see and comment if you see any more improvement on that. |
Filters appear to behave as negative filters, removing data from the output. Is this correct/intended?
This is a test harness I was using to determine filter behavior (called
genr.py
):If this is intended behavior, would you accept a PR updating the filter docs to mention this ?
The text was updated successfully, but these errors were encountered: