{"push_id":844916764,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"2639091f7f862eddfb3c9cc378453794a5007654","before":"0682548bcece40366104c2db0027b55b64045975","commits":[{"sha":"2639091f7f862eddfb3c9cc378453794a5007654","author":{"email":"f5f25150104e445be281fa3e96f4d2bf3a8cb24c@runbox.com","name":"Zoltan Somogyi"},"message":"Fix a performance problem in mode analysis.\n\nWhen working on the diff to make_hlds_passes.m, the compiler took effectively\nforever on an intermediate version; I killed it after about half an hour\nof CPU time. Invoking a debug version of the compiler on that version\nof make_hlds_passes.m and interrupting it several times while it was\ntwiddling its thumbs showed that it was spending its time in computing\na set of candidate vars for auto-initialization. Since the predicate\nit was analyzing at the time, do_parse_tree_to_hlds, is quite big and has\nlots of variables, the sets of candidate variables could be quite big,\nand may have to be computed lots of times. However, all those computations\nare wasted, since once the set of candidate vars is computed, mode analysis\nchecks if the variables in those sets have a solver type that has auto\ninitialization. In most predicates including this one, NO variable has\nsuch a type, so this test will fail.\n\ncompiler/modecheck_conj.m:\n    Test whether ANY variable in the procedure being analyzed has a solver\n    type with auto initialization. If not, don't bother to compute the\n    candidate vars.\n\ncompiler/mode_info.m:\n    When initializing the mode_info before starting to analyze a procedure,\n    record whether any its variables has a solver type with auto\n    initialization.\n\nThere is no test case for this performance bug. First, I don't understand\nthe algorithm that computes the candidate vars set well enough to hand craft\na small test that nevertheless tickles this worst-case behavior. Second,\ntrying to minimize the actual problem code would probably yield something\nthat is still way bigger than one of our usual test cases. And third,\nif the test case fails, it would do so by using huge amounts of CPU time\n*without* running out of stack, which is a pretty bad failure mode,\nand I have no idea how to impose a CPU time limit on a test case\nthat would also work on Windows. (The code in question is nondet, and\nevery backtrack to a choice point frees the det stack used up till then.)\n\nHowever, a hand test on the actual problem code (which is a snapshot\nof the offending version of the entire compiler directory) does show\nthat this diff fixes the problem.","distinct":true,"url":"https://api.github.com/repos/Mercury-Language/mercury/commits/2639091f7f862eddfb3c9cc378453794a5007654"}]}