Details
- Reviewers
alexfh sbenza bkramer george.karpenkov NoQ
Diff Detail
- Repository
- rL LLVM
Event Timeline
@lebedev.ri LLVM already has facilities for outputting statistics in JSON, it seems that would be sufficient for your purposes?
I did something similar for the static analyzer in https://reviews.llvm.org/D43131
YAML != JSON.
I did see all that TimerGroup stuff.
I will take a second look, but the dumpVal() change will still be needed either way.
- Drop CSV stuff
- Add constructor from previously-collected StringMap<TimeRecord>
- Make printJSONValues() public.
- Dump floating-point values in scientific format with full precision.
Add lock to now-public printJSONValues().
I have no understanding of the static TimerGroupList,
but this is symmetrical with other [public] TimerGroup::*print* methods.
I wonder why JSON? What kind of a tool do folks use to process the outputs of printJSONValue? Is there anything existing or is JSON used "just in case"? I personally use either spreadsheets, python or shell when I deal with this kind of data, and all three of them can work reasonably well with CSV (plus the data is pretty simple).
- Use sane (not the same as the one right before..) suffix for when json-printing mem usage. Admittedly, i haven't tried it, but it just does not make sense otherwise.
I see four separate changes: s/.sys/mem one (can be committed without review), exposing printJSONValues and consequent adding of a lock, adding a constructor accepting a map, and fixing formatting in printJSONValue. All four look good to me, but probably should be reviewed separately.
lib/Support/Timer.cpp | ||
---|---|---|
385 | This change seems unrelated to the new constructor accepting map, right? | |
405 | That's independent from this change, right? |
@alexfh & @george.karpenkov Thanks for reviewing those!
Not sure yet whether i will land them right away, or wait for clang-tidy part.
Not sure yet whether i will land them right away, or wait for clang-tidy part.
I think it's better to land, as otherwise you risk merge conflicts, and implicit conflicts (git reports no errors, but the resulting code is bad) can be very annoying.
This change seems unrelated to the new constructor accepting map, right?