aboutsummaryrefslogtreecommitdiffhomepage
path: root/test-suite/output-modulo-time
Commit message (Collapse)AuthorAge
* Fix ltacprof_abstract (I think because of #6411 parallel merge).Gravatar Gaëtan Gilbert2017-12-19
|
* Merge PR #6406: Make [abstract] nodes show up in the Ltac profileGravatar Maxime Dénès2017-12-18
|\
| * Make [abstract] nodes show up in the Ltac profileGravatar Jason Gross2017-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This closes #5082 and closes #5778, but makes #6404 apply to `abstract` as well as `transparent_abstract`. This is unfortunate, but I think it is worth it to get `abstract` in the profile (and therefore not misassign the time spent sending the subproof to the kernel). Another alternative would have been to add a dedicated entry to `ltac_call_kind` for `TacAbstract`, but I think it's better to just deal with #6404 all at once. The "better" solution here would have been to move `abstract` out of the Ltac syntax tree and define it via `TACTIC EXTEND` like `transparent_abstract`. However, the STM relies on its ability to recognize `abstract` and `solve [ abstract ... ]` syntactically so that it can handle `par: abstract`. Note that had to add locations to `TacAbstract` nodes, as I could not figure out how to call `push_trace` otherwise.
* | Fix #5081 by more fine-grained LtacProf recordingGravatar Jason Gross2017-12-12
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To fix #5081, that LtacProf associates time spent in tactic-evaluation with the wrong tactic, I added two additional calls to the profiler during tactic evaluation phase. These two calls do not update the call count of the relevant tactics, but simply add time to them. Although this fixes #5081, it introduces a new bug, involving tactics which are aliases of other tactics, which I am not sure how to fix. Here is the explanation of the issue, as I currently understand it (also recorded in a comment in `profile_ltac.mli`): Ltac semantics are a bit insane. There isn't really a good notion of how many times a tactic has been "called", because tactics can be partially evaluated, and it's unclear whether the number of "calls" should be the number of times the body is fetched and unfolded, or the number of times the code is executed to a value, etc. The logic in `Tacinterp.eval_tactic` gives a decent approximation, which I believe roughly corresponds to the number of times that the engine runs the tactic value which results from evaluating the tactic expression bound to the name we're considering. However, this is a poor approximation of the time spent in the tactic; we want to consider time spent evaluating a tactic expression to a tactic value to be time spent in the expression, not just time spent in the caller of the expression. So we need to wrap some nodes in additional profiling calls which don't count towards to total call count. Whether or not a call "counts" is indicated by the `count_call` boolean argument. Unfortunately, at present, we can get very strange call graphs when a named tactic expression never runs as a tactic value: if we have `Ltac t0 := t.` and `Ltac t1 := t0.`, then `t1` is considered to run 0(!) times. It evaluates to `t` during tactic expression evaluation, and although the call trace records the fact that it was called by `t0` which was called by `t1`, the tactic running phase never sees this. Thus we get one call tree (from expression evaluation) that has `t1` calls `t0` calls `t`, and another call tree which says that the caller of `t1` calls `t` directly; the expression evaluation time goes in the first tree, and the call count and tactic running time goes in the second tree. Alas, I suspect that fixing this requires a redesign of how the profiler hooks into the tactic engine.
* remove unneeded -emacs flag to coq-prog-argsGravatar Paul Steckler2017-05-01
|
* test-suite/output-modulo-time made more robustGravatar Enrico Tassi2016-09-30
| | | | Order of items made stable
* Merge remote-tracking branch 'github/pr/303' into v8.6Gravatar Maxime Dénès2016-09-30
|\ | | | | | | Was PR#303: LtacProf cutoff is for total percent, not time
| * LtacProf cutoff is for total percent, not timeGravatar Jason Gross2016-09-29
| |
* | Set the default LtacProf cutoff to 2%Gravatar Jason Gross2016-09-29
|/ | | | | | | | | | | This was the original value from Tobias' code. When a user passes -profile-ltac on the command line, or inserts [Show Ltac Profile] in the document, the most useful default behavior is to not overload them with useless information. When GUI clients want to display fancier profiling information, there is no cost to the user to requiring them to specify what cutoff they want. If the GUI client does not have any special LtacProf handling, the most useful presentation is again the one that cuts off the display at 2% total time.
* Add support for testing output mod timing changesGravatar Jason Gross2016-09-11
Uses sed 's/\s*[0-9]*\.[0-9]\+\s*//g' and 's/\s*0\.\s*//g' to strip numbers of seconds and to strip percentages. (This can potentially be extended later.) Add a test-suite file to make sure that LtacProf outputs some table.