From: bgamari.foss@gmail.com (Ben Gamari)
Subject: [sup-talk] Crash while scrolling
Date: Thu, 01 Oct 2009 13:44:19 -0400 [thread overview]
Message-ID: <1254418089-sup-5800@ben-laptop> (raw)
In-Reply-To: <1254404181-sup-8448@masanjin.net>
Excerpts from William Morgan's message of Thu Oct 01 09:43:48 -0400 2009:
> Reformatted excerpts from Ben Gamari's message of 2009-09-28:
> > This actually brings up a larger question. How difficult would it be
> > to relax sup's assumption that sources are add-only?
>
> It's not difficult per se, it just requires scanning over the entire
> source, which is slow. Removing this assumption would be tantamount to
> running sup-sync -c every time you start up sup.
>
> Here's the idea: scanning over a mailstore is slow. Much of this
> slowness is due to Ruby. So let's rewrite this code in C. Then we would
> have something as fast as, say, Mutt. But Mutt bogs down on my mbox file
> because it's too big. So my *only* reasonable choice with a large
> mailstore is Sup and the assumption that the source is add only.
It seems that C would definitely be a good start (or perhaps C++ would
be a better idea as that is the language in which Xapian is written).
However, I think one of the real issues is the exclusive nature of index
access. In fact, this is one of my primary gripes with the sup
workflow. After processing a large number of messages, the write-out
time can be quite substantial upon killing the buffer. This can be a
noticeable interruption to workflow. It seems to me that index access
should be asynchronous at least.
If this were the case, then we could get support for mutable sources for
free, as we could synchronize against sources without interrupting
workflow (although keeping the view in sync with the backend would be a
bit tricky).
As an aside, it would be quite nice if one could run multiple
simultaneous instances of sup. It seems that if one only held write access
to the index during writes (is this the case presently?), there should
be nothing preventing this from being possible.
Correct me if I'm wrong in any part of my above assessment. Hope things
are going well,
- Ben
next prev parent reply other threads:[~2009-10-01 17:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 16:58 Ben Gamari
2009-09-12 16:35 ` William Morgan
2009-09-13 15:02 ` Ben Gamari
2009-09-16 17:23 ` Ben Gamari
2009-09-26 14:31 ` William Morgan
2009-09-28 18:10 ` Ben Gamari
2009-10-01 13:43 ` William Morgan
2009-10-01 17:44 ` Ben Gamari [this message]
2009-10-01 18:31 ` William Morgan
2009-10-01 19:01 ` Ben Gamari
2009-10-11 20:31 ` William Morgan
2009-10-01 18:41 ` [sup-talk] Writing time-sensitive portions of sup in C Carl Worth
2009-09-30 21:21 ` [sup-talk] Crash while scrolling William Morgan
2009-10-04 19:59 ` Guillaume Quintard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1254418089-sup-5800@ben-laptop \
--to=bgamari.foss@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox