On Sun, 27 Nov 2011 13:40:53 -0500, Tom Prince wrote:
> From: Thomas Schwinge
>
> Asking xapian to sort the messages for us causes suboptimal IO patterns. This
> would be useful, if we only wanted the first few results, but since we want
> everything anyway, this is pessimization.
Pushed.
d
__
Hi!
First, thanks to David, Tomi, Tom for moving this forward.
On Sat, 19 Nov 2011 16:11:13 +0100, Petter Reinholdtsen wrote:
> [Thomas Schwinge]
> > +/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a
> > measurement
> > + * on a 372981 messages instance showed that wall t
On Sun, 27 Nov 2011 13:40:53 -0500, Tom Prince
wrote:
> From: Thomas Schwinge
>
> Asking xapian to sort the messages for us causes suboptimal IO patterns. This
> would be useful, if we only wanted the first few results, but since we want
> everything anyway, this is pessimization.
Pushed.
d
Hi!
First, thanks to David, Tomi, Tom for moving this forward.
On Sat, 19 Nov 2011 16:11:13 +0100, Petter Reinholdtsen
wrote:
> [Thomas Schwinge]
> > +/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a
> > measurement
> > + * on a 372981 messages instance showed that wall
From: Thomas Schwinge
Asking xapian to sort the messages for us causes suboptimal IO patterns. This
would be useful, if we only wanted the first few results, but since we want
everything anyway, this is pessimization.
On 2011-10-29, a measurement on a 372981 messages instance showed that wall
ti
From: Thomas Schwinge
Asking xapian to sort the messages for us causes suboptimal IO patterns. This
would be useful, if we only wanted the first few results, but since we want
everything anyway, this is pessimization.
On 2011-10-29, a measurement on a 372981 messages instance showed that wall
ti
On Mon, 14 Nov 2011 21:10:44 -0400, David Bremner wrote:
> On Sat, 29 Oct 2011 12:37:37 +0200, Thomas Schwinge
> wrote:
> > From: Thomas Schwinge
> >
> > This improves usage experience considerably in the given scenario.
> >
>
> I'm not sure if I mentioned this only in IRC, so let me recap.
On Mon, 14 Nov 2011 21:10:44 -0400, David Bremner wrote:
> On Sat, 29 Oct 2011 12:37:37 +0200, Thomas Schwinge
> wrote:
> > From: Thomas Schwinge
> >
> > This improves usage experience considerably in the given scenario.
> >
>
> I'm not sure if I mentioned this only in IRC, so let me recap.
[Thomas Schwinge]
> +/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a
> measurement
> + * on a 372981 messages instance showed that wall time can be reduced
> from
> + * 28 minutes (sorted by Message-ID) to 15 minutes (unsorted), the latter
> + * being much more ``d
[Thomas Schwinge]
> +/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a
> measurement
> + * on a 372981 messages instance showed that wall time can be reduced
> from
> + * 28 minutes (sorted by Message-ID) to 15 minutes (unsorted), the latter
> + * being much more ``d
On Sat, 29 Oct 2011 12:37:37 +0200, Thomas Schwinge
wrote:
> From: Thomas Schwinge
>
> This improves usage experience considerably in the given scenario.
>
I'm not sure if I mentioned this only in IRC, so let me recap.
Personally, I think this needs more information in the commit message,
an
On Sat, 29 Oct 2011 12:37:37 +0200, Thomas Schwinge
wrote:
> From: Thomas Schwinge
>
> This improves usage experience considerably in the given scenario.
>
I'm not sure if I mentioned this only in IRC, so let me recap.
Personally, I think this needs more information in the commit message,
an
From: Thomas Schwinge
This improves usage experience considerably in the given scenario.
---
Hi!
I decided that it'd be useful to put the reasoning and data right next to
the source code (as opposed to putting it into the commit message), for
the next guy to read this code has it all in one p
From: Thomas Schwinge
This improves usage experience considerably in the given scenario.
---
Hi!
I decided that it'd be useful to put the reasoning and data right next to
the source code (as opposed to putting it into the commit message), for
the next guy to read this code has it all in one p
14 matches
Mail list logo