<feed xmlns='http://www.w3.org/2005/Atom'>
<title>notmuch/performance-test/Makefile.local, branch 0.15.1</title>
<subtitle>thread-based email index, search, and tagging</subtitle>
<id>https://git.notmuchmail.org/git/notmuch/atom?h=0.15.1</id>
<link rel='self' href='https://git.notmuchmail.org/git/notmuch/atom?h=0.15.1'/>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/'/>
<updated>2012-12-25T12:49:24Z</updated>
<entry>
<title>perf-test: initial version of memory test infrastructure.</title>
<updated>2012-12-25T12:49:24Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2012-12-16T12:33:17Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=098ef4af4d0a52a6b4daed5324a7c77f6c9108da'/>
<id>urn:sha1:098ef4af4d0a52a6b4daed5324a7c77f6c9108da</id>
<content type='text'>
The idea is run some code under valgrind --leak-check=full and report
a summary, leaving the user to peruse the log file if they want.

We go to some lengths to preserve the log files from accidental
overwriting; the full corpus takes about 3 hours to run under valgrind
on my machine.

The naming of the log directories may be slightly controversial; in
the unlikely event of two runs in less than a second, the log will be
overwritten. A previous version with mktemp+timestamp was dismissed as
overkill; just mktemp alone does not sort nicely.

One new test is included, to check notmuch new for memory leaks.
</content>
</entry>
<entry>
<title>perf-test: rename current tests as "time tests"</title>
<updated>2012-12-25T12:49:24Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2012-12-16T14:55:51Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=047cd7a595f760a23415b9e38d7136325f28b114'/>
<id>urn:sha1:047cd7a595f760a23415b9e38d7136325f28b114</id>
<content type='text'>
This is almost entirely renaming files, except for updating a few
references to those file names, and changing the makefile target.

A new set of memory tests will be run separately because they take
much longer.
</content>
</entry>
<entry>
<title>perf-test: add caching of xapian database</title>
<updated>2012-12-15T12:17:58Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2012-12-03T12:48:53Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=ceaf5ca6c02e494eee5b9b9aa955459b3cd29471'/>
<id>urn:sha1:ceaf5ca6c02e494eee5b9b9aa955459b3cd29471</id>
<content type='text'>
The caching and uncaching seem to be necessarily manual, as timing the
initial notmuch new is one of our goals with this suite.
</content>
</entry>
<entry>
<title>perf-test: cache unpacked corpus</title>
<updated>2012-12-15T12:17:57Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2012-12-03T12:13:31Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=74a883562b3e4593c75fa7625ff5cabab46a6466'/>
<id>urn:sha1:74a883562b3e4593c75fa7625ff5cabab46a6466</id>
<content type='text'>
Unpacking is not really the expensive step (compared to the initial
notmuch new), but this is a pre-requisite to caching the database.
</content>
</entry>
<entry>
<title>test: initial performance testing infrastructure</title>
<updated>2012-11-26T12:39:21Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2012-11-17T16:28:15Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=7beeb8c88a014ecbc53d8241f10683b3c4c16228'/>
<id>urn:sha1:7beeb8c88a014ecbc53d8241f10683b3c4c16228</id>
<content type='text'>
This is not near as fancy as as the unit tests, on the theory that
the code should typically be crashing when performance tuning.
Nonetheless, there is plenty of room for improvement.  Several more of
the pieces of the test infrastructure (e.g. the option parsing) could
be factored out into test/test-lib-common.sh
</content>
</entry>
</feed>
