Fix a performance bug (again) due to verbose printing not being lazy.
The only culprit was the one in unifyClock.ml::249, but I've lazyfied most of the non-trivial verbose call. The 2 remaining unresolved testq that were timeout-ing now pass in a few ms... The whole non-reg test time has been divided by more than 2!
Showing
- src/ast2lic.ml 3 additions, 3 deletionssrc/ast2lic.ml
- src/evalClock.ml 5 additions, 4 deletionssrc/evalClock.ml
- src/l2lExpandArrays.ml 3 additions, 3 deletionssrc/l2lExpandArrays.ml
- src/l2lExpandMetaOp.ml 3 additions, 2 deletionssrc/l2lExpandMetaOp.ml
- src/l2lExpandNodes.ml 4 additions, 3 deletionssrc/l2lExpandNodes.ml
- src/l2lRmPoly.ml 7 additions, 5 deletionssrc/l2lRmPoly.ml
- src/l2lSplit.ml 5 additions, 4 deletionssrc/l2lSplit.ml
- src/lic.ml 3 additions, 2 deletionssrc/lic.ml
- src/licEvalType.ml 3 additions, 2 deletionssrc/licEvalType.ml
- src/licPrg.ml 2 additions, 1 deletionsrc/licPrg.ml
- src/licTab.ml 35 additions, 29 deletionssrc/licTab.ml
- src/unifyClock.ml 3 additions, 2 deletionssrc/unifyClock.ml
- src/verbose.mli 1 addition, 1 deletionsrc/verbose.mli
- test/lus2lic.log.ref 7 additions, 8 deletionstest/lus2lic.log.ref
- test/lus2lic.sum 4 additions, 5 deletionstest/lus2lic.sum
- test/lus2lic.time 2 additions, 2 deletionstest/lus2lic.time
- todo.org 3 additions, 22 deletionstodo.org
- todo.org_archive 31 additions, 0 deletionstodo.org_archive
Loading
Please register or sign in to comment