-
Notifications
You must be signed in to change notification settings - Fork 10
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
(Possibly) Overhaul Instrumentation Framework #359
Comments
It turned out Tom's recent changes did not require "free-form" instrumentation data, so this has become somewhat lower priority. The PyPy idea is still valid. |
Ideally, Krun would support "plugins", where each plugin would consist of:
As it stands both of these are hard-coded into Krun, and the instrumentation interface is not great either. To fix #366, we are planning on adding some environment variables or arguments to the iterations runners to pass:
This gives the iteration runner itself enough information to open a file and dump instrumentation data into it. Perhaps this would be a better interface than expecting the VMs to spew stuff onto stderr for Krun to pick up and store later? Porting the existing instrumentation code and various scripts (plotting! the horror) is not a small change however. |
The instrumentation data and plotting should be reasonably well decoupled already. class ChartData(object):
"""Class to hold data needed by the plotting script.
Each VM parser may parse a number of different events which need to be
plotted (e.g. compilation events, GC, etc.). These should be stored in
a list of ChartData objects, so that the plotting script does not have to
know anything about the individual VMs.
"""
def __init__(self, title, data, legend_text):
self.title = title
self.data = data
self.legend_text = legend_text So, hopefully, the most you would need to do is re-write the parsers, or the place where the instrumentation files are loaded. |
Currently the instrumentation framework expects the iteration runner to give one "packet" of data per in-process iteration. This is somewhat rigid, e.g. one cannot emit data that applys for a whole process execution or more generally arbitrary data.
Another idea: summarise the PyPy instrumentation data at experimentation time so that it is smaller to parse later.
The text was updated successfully, but these errors were encountered: