Olly Betts <olly at survex.com> writes:> > So the T00-new.sh numbers make sense - there's more work to do, and > we need to read existing positional data more to insert the new stuff, > so the increased reads and writes make sense. > > But guessing at what the other two tests do, I wouldn't expect them to > be affected by this.The non-optimized-away cases of T02-tag just adding and deleting terms to each document with term Tmail> I'm also a bit puzzled by how glass can manage not to read any data > for "dump *", and several tests seem to not read or write anything > for either backend. What exactly are the "In/Out" numbers?that's just the output from /usr/bin/time -f '%e\t%U\t%S\t%M\t%I/%O' The manual describes them as "number of file system inputs/outputs". From looking at the source, they correspond to ru_inblock and ru_oublock fields from the getrusage call. AFAIU, that means the number of non-cached read/writes. d
On Thu, Apr 07, 2016 at 09:40:59PM -0300, David Bremner wrote:> Olly Betts <olly at survex.com> writes: > > > > > So the T00-new.sh numbers make sense - there's more work to do, and > > we need to read existing positional data more to insert the new stuff, > > so the increased reads and writes make sense. > > > > But guessing at what the other two tests do, I wouldn't expect them to > > be affected by this. > > The non-optimized-away cases of T02-tag just adding and deleting terms > to each document with term TmailThat should short-cut to just only changing the data for Tmail. Perhaps that's not working correctly - I'll take a look at this, but probably after 1.4.0 is out.> > I'm also a bit puzzled by how glass can manage not to read any data > > for "dump *", and several tests seem to not read or write anything > > for either backend. What exactly are the "In/Out" numbers? > > that's just the output from /usr/bin/time -f '%e\t%U\t%S\t%M\t%I/%O' > > The manual describes them as "number of file system > inputs/outputs". From looking at the source, they correspond to > ru_inblock and ru_oublock fields from the getrusage call. AFAIU, that > means the number of non-cached read/writes.Non-cached reads/writes are arguably the most useful sort to measure, but the reads at least will be sensitive to OS caching, which means a repeat run will generally show lower numbers of reads, e.g.: $ /usr/bin/time -f '%I/%O' wc randomfile 240 2908 96780 randomfile 192/0 $ /usr/bin/time -f '%I/%O' wc randomfile 240 2908 96780 randomfile 0/0 So those numbers may not be entirely comparable, depending what order your tests were done in, and whether you'd run the tests (or cloned the repo or some other operation which read or wrote the files used) recently enough that their data might still be cached. Cheers, Olly
Olly Betts <olly at survex.com> writes:> Non-cached reads/writes are arguably the most useful sort to measure, but the > reads at least will be sensitive to OS caching, which means a repeat run will > generally show lower numbers of reads, e.g.: > > $ /usr/bin/time -f '%I/%O' wc randomfile > 240 2908 96780 randomfile > 192/0 > $ /usr/bin/time -f '%I/%O' wc randomfile > 240 2908 96780 randomfile > 0/0 > > So those numbers may not be entirely comparable, depending what order your > tests were done in, and whether you'd run the tests (or cloned the repo or some > other operation which read or wrote the files used) recently enough that their > data might still be cached.Here are the number from second glass run. The order was glass / chert / glass T00-new.sh: Testing notmuch new [0.4 large] Wall(s) Usr(s) Sys(s) Res(K) In/Out(512B) Initial notmuch new 920.53 698.96 207.02 245188 3528/22442096 notmuch new #2 0.55 0.00 0.01 8048 6960/160 notmuch new #3 0.01 0.00 0.00 8112 0/8 notmuch new #4 0.01 0.01 0.00 8136 0/8 notmuch new #5 0.01 0.00 0.00 8140 0/8 notmuch new #6 0.01 0.00 0.00 8116 0/8 T01-dump-restore.sh: Testing dump and restore [0.4 large] Wall(s) Usr(s) Sys(s) Res(K) In/Out(512B) load nmbug tags 8.89 4.23 3.88 11648 368/40072 dump * 7.37 6.29 1.08 25268 72/27928 restore * 7.60 7.16 0.43 8624 0/0 T02-tag.sh: Testing tagging [0.4 large] Wall(s) Usr(s) Sys(s) Res(K) In/Out(512B) tag * +new_tag 474.16 274.89 191.52 34820 16/1920240 tag * +existing_tag 0.01 0.01 0.00 8480 152/0 tag * -existing_tag 438.62 239.02 195.44 34928 0/1970160 tag * -missing_tag 0.00 0.00 0.00 8264 0/0 It's a bit faster overall, but not radically so. So I think cache effects are not the main issue here.