Skip to content
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

"txn" feature not usable due to integrated Perfspect #178

Open
hsane-dev opened this issue Jan 28, 2025 · 3 comments · May be fixed by #192
Open

"txn" feature not usable due to integrated Perfspect #178

hsane-dev opened this issue Jan 28, 2025 · 3 comments · May be fixed by #192
Labels
enhancement New feature or request

Comments

@hsane-dev
Copy link

The "txn" feature which is meant to normalize data by txn, now requires it to be given at collection time due to integrated nature of Perfspect (as opposed to collect and process later). This means that a "txn" value has to be provided ahead of time or a prior value has to be used, which may be inaccurate.
Can Perfspect still do later post-processing OR allow reading the "txn" value from a pipe which can essentially be an API endpoint frm some application reading its "txn" value through the time its collecting?

@harp-intel
Copy link
Contributor

Agree this is a limitation to the integrated collection/reporting design.

@harp-intel
Copy link
Contributor

I have an idea for how to address this, but it will take some time. In general, the idea is similar to functionality in some of the other commands, e.g., report, flame, telemetry. They accept an 'input' flag that points to a file or directory containing the raw data. They use the 'input' data instead of collecting new data.

The 'metrics' command currently supports the --raw flag which writes the perf events and metadata to files in the output directory. These could be used as 'input'.

@harp-intel harp-intel added the enhancement New feature or request label Jan 28, 2025
@hsane-dev
Copy link
Author

That would work, essentially performing post-processing later. Another idea would be to provide a filename or some form of pointer instead of the "txn value." Once it becomes available from the app, the post-processing continues—though admittedly, this increases dependency and the possibility of errors.

@harp-intel harp-intel linked a pull request Feb 4, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants