Replies: 3 comments 4 replies
-
The primary problem here is "all". You are right that writing to JSON serialization the same way as the text log is more complicated. The reason that "all" is a problem is that "all" would essentially require dynamic memory allocation in the sample member function (or a relatively complex buffering system to avoid it). Since that function is called from a signal handler, a long running application would have a high probability of overflowing the signal stack. However, adding support for something like |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Sample JSON: {
"timemory": {
"command_line": [
"./timem",
"sleep",
"10"
],
"config": {
"use_shell": false,
"use_mpi": false,
"use_papi": true,
"use_sample": true,
"debug": false,
"verbose": -1,
"shell": "/bin/bash",
"shell_flags": "",
"sample_freq": 500.0,
"sample_delay": 0.000001,
"buffer_size": 500
},
"timem": [
{
"wall_clock": {
"value": 9.609806793,
"repr": 9.609806793,
"laps": 5000,
"unit_value": 1,
"unit_repr": "sec"
},
"user_clock": {
"value": 0.0,
"repr": 0.0,
"laps": 5000,
"unit_value": 1,
"unit_repr": "sec"
},
...
"history": [
{
"sample_timestamp": {
"localtime": "Mon Sep 27 21:53:02 2021 CDT",
"time_since_epoch": 1632797582273282394
},
"wall_clock": {
"value": 0.002000507,
"repr": 0.002000507,
"laps": 1,
"unit_value": 1,
"unit_repr": "sec"
},
"user_clock": {
"value": 0.0,
"repr": 0.0,
"laps": 0,
"unit_value": 1,
"unit_repr": ""
},
... |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pretty much what the title says. As of today,
timemonly writes the last sample to its JSON output file, and while it can be instructed to log every sample by turning up verbosity, it does so in a non-structured way which makes it hard for downstream tooling to pick it up.So how about populating
"timem"array with all samples (on request)? It appears to me thattim::cereal::PrettyJSONOutputArchivecan be told to output an array. Serializing ontimem_tuple::samplewould be straightforward, although writes or exits from signal handlers would no longer be possible (as the archive's destructor must be invoked and the output file flushed or the resulting JSON will be broken).I also understand
timemis there to demonstrate some oftimemory's (many) features, and perhaps this works against that. Not sure. I just wanted to bring this up before I roll out atimemvariation of my own.Beta Was this translation helpful? Give feedback.
All reactions