RE: Another problem to look at.
"Welch, Brent" <[email protected]> Mon, 23 Apr 2012 19:10:41 +0000
| Newsgroups | gmane.mail.exmh.user |
|---|---|
| Message-ID | <DA636AC7BF798243A4007D3AA0B3D3A746E9AADE@seabiscuit.int.panasas.com> |
Yeah, you really want that scanSize preference setting. That's exactly why it exists.
It seems unlikely that changing the insert call from one big one too many small ones would be faster.
The Tk C library is building its data structure, which is what you are paying for.
Anyway, to try it, it would be something like this:
foreach line [split $text \n] {
$exwin(ftext) insert end $text\n
}
--
Brent
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Monday, April 23, 2012 6:08 AM
To: Discussion list for EXMH users
Subject: Re: Another problem to look at.
On Sun, 22 Apr 2012 23:46:36 -0600, [email protected] said:
> If the number of articles in a give directory get to 32k (or mabe 65k)
> the initial startup of EXMH just stalls when it gets to this group.
> And its easy to get these large number of articles in groups like gnu.
> Im sure it is just the width of some field somewhere, but Ive never
> been able to find it.
If it's what I think it is...
The problem is that if the .xmhcache file is out of date for that directory,
exmh has to rebuild it by running 'scan'. Adding "*scanSize: 1000" will
make it do a 'scan last:1000' (for a suitable value of 1000). There's a tradeoff
here - things go a lot faster but the scan pane only lists the last N items
and you need to hit 're-scan folder' to see more.
The crazy part is that I once benched this out, and here's the offender in scan.cl:
proc ScanFolder does this:
set input [open "|$mhProfile(scan-proc) [list +$folder] \
last:$ftoc(scanSize) -width $ftoc(scanWidth) -noheader"]
...
ScanAddLines [read $input]
proc ScanAddLines { text } {
global exwin
$exwin(ftext) insert end $text
}
and that ends up being incredibly expensive if $text is large - it appears that
'insert end' CPU usage is O(n**2) or worse on size of $text. It might be
interesting to see if there's a speedup by converting it from one call to a
while loop that does one line at a time. Or did we try that at one time and
those results were even worse?