Feature request & sample implementation: Ignore repeated methods
Closed this issue · 4 comments
In the UI, it is nice to add a feature, whereby you check the checkbox "ignore repeated methods", and it will start storing all the method names in a set. If a method name is repeated, it won't output that same method name again..
Thereby, you are filtering out all methods that were previously displayed.
This is great for reverse engineering, allowing one to capture noisy methods that aren't part of the application, and then only display new methods based on some user action, etc..
I did an initial implementation here:
Can you confirm the state of your initial implementation - does it work? Are there any limitations?
One of the biggest problems with InTrace is that the output is very noisy so I'm intrigued by this idea. Can you provide more details about the use case which you have in mind? It sounds almost like a way of getting a sort of runtime live code coverage. In other words when you interact with an application you could see in real time whether any new methods are being hit.
However, if this is the case I wonder if a proper code coverage tool would be more useful. What do you think?
Hi.. I have used it for a day or two, and it seems to work, but haven't tested it extensively. Perhaps you would know the code more to spot any side cases or potential threading issues, etc..
The use case I used it for.. For example, I'm debugging IntelliJ IDEA's IDE. I capture a bunch of classes, to see what they do. However, a bunch of them, are highly noisy because they are related to event loops and other background things going on in the system that I'm not interested in.. So I capture all those methods, and ignore them. Now I do some user action, and pay attention to these new methods that are being called. These methods are more specific to the user action I just did, and it doesn't display the noisy methods of the more general-purpose code and event handling infrastructure, that I'm not interested in.
If you "uncheck" capturing new methods, then it displays all the method's that get invoked, that do not match this filtering criteria. Now show repeated method sends for methods that are not contained in the original "caputred" set, will be displayed in regular sequential order as it would with typical use of your tool. So really, here, you've just created a more sophisticated filtering criteria. I think this idea is more of an extension of your tool than it is code coverage.
Code Coverage tools might be another approach too, I'm just not sure if they would be as interactive as this. In fact, the whole point of capturing the methods of interest, has everything to do with the interactivity. Code coverage tool might show you a bunch of innards of a highly-called event-handling mechanism, which might not be of interest when you're trying to figure out what classes are involved with a particular user interaction, etc.. ?
If you know of some that would be very interactive in this sort of way I'd like to try them, I couldn't seem to really find any that fit the criteria. If you know of any that would be suitable for this use case, I'd like to try them.
Thanks for this write up. I hadn't considered the two phase approach which you describe where this new feature is used to quickly establish a useful filter of framework classes.
I don't know of any live code coverage tools - its just the comparison which occurred to me.
I will grab your changes at some point in the next few weeks and do an InTrace release to include them. Thanks for this contribution!
I've pulled your changes into my repository. I will do a release shortly which will include the change.