Re: [Maria-developers] [Commits] Rev 2999: Speed up `mtr --parallel=<lots>` by scheduling some slow tests earlier. in http://bazaar.launchpad.net/~maria-captains/maria/5.1
![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
Hi, knielsen! On Jan 03, knielsen@knielsen-hq.org wrote:
Hm. Why do you prefer to add a dummy include file to every "long" test, instead of using a separate file, like disabled.def ? I think it'd be easier to maintain in a separate file, and easier to extend later on. Regards, Sergei
![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Sergei Golubchik
Hm. Why do you prefer to add a dummy include file to every "long" test, instead of using a separate file, like disabled.def ?
I thought it was simpler to re-use an existing mechanism. The mtr_cases.pm already parses out lots of info about test cases in this way.
I think it'd be easier to maintain in a separate file, and easier to extend later on.
Why? What I'd really like is something that didn't have to be maintained. Eg. the test run could store actual test case times in some $HOME/.mtr/timings.txt, and use that for scheduling in subsequent runs. But for this, I'd just gotten so annoyed about always waiting a couple of minutes extra for that final partitioning test for so long that I finally made a quick minimal solution... - Kristian.
![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
Hi, Kristian! On Jan 03, Kristian Nielsen wrote:
Sergei Golubchik
writes: Hm. Why do you prefer to add a dummy include file to every "long" test, instead of using a separate file, like disabled.def ?
I thought it was simpler to re-use an existing mechanism. The mtr_cases.pm already parses out lots of info about test cases in this way.
disabled.def is also an existing mechanism, in a sense. So there's a precedent for both approaches :)
I think it'd be easier to maintain in a separate file, and easier to extend later on.
Why?
What I'd really like is something that didn't have to be maintained. Eg. the test run could store actual test case times in some $HOME/.mtr/timings.txt, and use that for scheduling in subsequent runs.
Right, that's exactly what I thought as an "extension later on". E.g. if you store long tests in a file, say, mysql-test/longtests.def then mysql-test/Makefile.am could have timings.txt: longtests.def cp longtests.def timings.txt and even without the code to update the file with actual timing, it will still work! I could've added the code to store actual timing next time when I get annoyed that execution time is predicted incorrectly :) Regards, Sergei
participants (2)
-
Kristian Nielsen
-
Sergei Golubchik