diff options
author | John Mainzer <mainzer@hdfgroup.org> | 2005-01-24 21:02:48 (GMT) |
---|---|---|
committer | John Mainzer <mainzer@hdfgroup.org> | 2005-01-24 21:02:48 (GMT) |
commit | 866b37b337c959c9c28febb6a5aef9644c592652 (patch) | |
tree | c951145fd29cc654153763357e79418ea0bef41d /tools/h5ls/h5ls.c | |
parent | 0fbfc1f7ed1ed0c12e940bd5a4f78b36ff336d0d (diff) | |
download | hdf5-866b37b337c959c9c28febb6a5aef9644c592652.zip hdf5-866b37b337c959c9c28febb6a5aef9644c592652.tar.gz hdf5-866b37b337c959c9c28febb6a5aef9644c592652.tar.bz2 |
[svn-r9868] Purpose:
Reduce the run time of the cache tests.
Description:
Some of the cache tests run for quite a while, which has been
causing problems with our daily build and test. In my last
modification to cache.c, I added code to skip these stress
tests unless we were building in production mode. Since
things go faster in production mode, the extra tests are not
a major problem here.
However, this means that the stress tests are only run once
or twice a week.
Solution:
To try to deal with this, I modified the four longest tests
to throttle depending on whether NDEBUG is defined. When
NDEBUG is not defined, runtime for the cache tests should
be about 1/5th its regular run time. We will see if this
is enough of a reduction to avoid problems.
There is some doubt in my mind as to just how much good the
throttled tests do, but they should be better than nothing.
As mentioned before, the correct solution is to build some
proper, random test code.
Platforms tested:
h5committested
production and debug builds on heping.
Misc. update:
Diffstat (limited to 'tools/h5ls/h5ls.c')
0 files changed, 0 insertions, 0 deletions