Hi!
First, thanks to David, Tomi, Tom for moving this forward.
On Sat, 19 Nov 2011 16:11:13 +0100, Petter Reinholdtsen p...@hungry.com wrote:
[Thomas Schwinge]
+/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a
measurement
+ * on a 372981 messages instance showed
On Sun, 27 Nov 2011 13:40:53 -0500, Tom Prince tom.pri...@ualberta.net wrote:
From: Thomas Schwinge tho...@schwinge.name
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
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
From: Thomas Schwinge tho...@schwinge.name
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
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 da...@tethera.net wrote:
On Sat, 29 Oct 2011 12:37:37 +0200, Thomas Schwinge tho...@schwinge.name
wrote:
From: Thomas Schwinge tho...@schwinge.name
This improves usage experience considerably in the given scenario.
I'm not sure if I
[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
[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
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,
On Sat, 29 Oct 2011 12:37:37 +0200, Thomas Schwinge tho...@schwinge.name
wrote:
From: Thomas Schwinge tho...@schwinge.name
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
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
From: Thomas Schwinge tho...@schwinge.name
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
14 matches
Mail list logo