summaryrefslogtreecommitdiffstats
path: root/tools/h5ls/h5ls.c
diff options
context:
space:
mode:
authorJohn Mainzer <mainzer@hdfgroup.org>2005-01-24 21:02:48 (GMT)
committerJohn Mainzer <mainzer@hdfgroup.org>2005-01-24 21:02:48 (GMT)
commit866b37b337c959c9c28febb6a5aef9644c592652 (patch)
treec951145fd29cc654153763357e79418ea0bef41d /tools/h5ls/h5ls.c
parent0fbfc1f7ed1ed0c12e940bd5a4f78b36ff336d0d (diff)
downloadhdf5-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