Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T6824 improve testing | ||
Open | None | T6825 optimize tests | ||
Open | None | T6831 optimize eina tests | ||
Resolved | zmike | T6829 inlist | ||
Resolved | None | T6830 rbtree | ||
Resolved | None | T6832 barrier | ||
Resolved | None | T6833 list | ||
Resolved | zmike | T6835 strbuf | ||
Resolved | None | T6836 safepointer | ||
Resolved | None | T6839 hash | ||
Resolved | cedric | T6841 fp | ||
Resolved | None | T6842 file | ||
Resolved | None | T6843 *share | ||
Resolved | None | T6845 locks | ||
Resolved | None | T6846 slstr |
I've done about all I can here without going into micro-optimizations. There are currently no tests which take even 0.1s to run, a handful of tests which take between 0.01-0.09s to run, yet a full eina_suite run somehow takes ~2.5s.
Examining libcheck, it seems like there's a hard limit here due to how check works: each test can be run in a forked process, but they are always run sequentially. This means that running each test has a fixed cost: I would speculate something like 0.03s per test case, meaning that for every ~30 tests we have, there is a minimum of 1 second in just setting up and waiting for the test to complete. This seems a bit bad for eina, being that it's artificially adding something like 2 seconds to each run, but it's even worse for elm which currently has 70ish tests and there should likely be many more added.
I think I may spend some time next week seeing how much work it would be to add parallel test runs to libcheck.