[PATCH] D46602: [clang-tidy] Store checks profiling info as YAML files

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh requested changes to this revision.
alexfh added a comment.
This revision now requires changes to proceed.

In https://reviews.llvm.org/D46602#1095980, @lebedev.ri wrote:

> In https://reviews.llvm.org/D46602#1095960, @alexfh wrote:
>
> > In https://reviews.llvm.org/D46602#1092902, @lebedev.ri wrote:
> >
> > > In https://reviews.llvm.org/D46602#1092890, @alexfh wrote:
> > >
> > > > Roman, it looks to me that a simpler storage scheme would be sufficient. For example, YYYYMMDDhhmmss-InputFileName.cpp.csv.
> > > >  Main things are:
> > > >
> > > > 1. include a timestamp, so there's no need to overwrite old results,
> > >
> > >
> > > Of the input source file?
> >
> >
> > No, current timestamp, when each profile gets dumped.
>
>
> Ah.
>  Then i don't understand this at all. Why would we want to do that, exactly?
>  Just so that we can avoid creating directory structure? Why do we want to avoid that?


If clang-tidy is invoked manually, a simpler naming scheme with less configuration options would be easier to use, in particular:

1. no the need to specify the `-store-check-profile-elide-prefix=` option;
2. it's easier to see all results (no need to use `find`, just `ls /output/directory` or `ls /output/directory/20180514*` to see today's results, for example);
3. no chance of filename collision, and thus no chance of losing older results by just running clang-tidy again.

If clang-tidy is started by a script (e.g. run-clang-tidy.py or a modification of it specialized on profiling), then a specific naming scheme doesn't matter much, since the script can create a separate directory for each run or for each shard. I don't yet see how repeating the directory structure of the input files would make profiling results easier or more convenient to use. A relation between the input file and the result file can still be maintained in some other form (for example, by specifying the whole invocation inside the results file - if we want to use YAML).


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D46602