From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/69284 Path: news.gmane.org!not-for-mail From: Dan Christensen Newsgroups: gmane.emacs.gnus.general Subject: Re: faster gnus-thread-latest-date Date: Sun, 13 Dec 2009 18:25:55 -0500 Message-ID: <87bpi2zcak.fsf@uwo.ca> References: <87my1uiien.fsf@uwo.ca> <87hbs2yw7f.fsf@uwo.ca> <87aaxt6zwy.fsf@lifelogs.com> <873a3lj89l.fsf@uwo.ca> <87y6lbfs42.fsf@uwo.ca> <87d42m2ozw.fsf@uwo.ca> <871vj1184a.fsf@uwo.ca> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1260747137 9510 80.91.229.12 (13 Dec 2009 23:32:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Dec 2009 23:32:17 +0000 (UTC) Cc: Dave Love To: ding@gnus.org Original-X-From: ding-owner+M17689@lists.math.uh.edu Mon Dec 14 00:32:10 2009 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1NJxv7-00088k-VG for ding-account@gmane.org; Mon, 14 Dec 2009 00:32:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1NJxpY-0008JK-Pj; Sun, 13 Dec 2009 17:26:24 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NJxpW-0008J6-2Q for ding@lists.math.uh.edu; Sun, 13 Dec 2009 17:26:22 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1NJxpS-0000iI-R5 for ding@lists.math.uh.edu; Sun, 13 Dec 2009 17:26:21 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1NJxpS-00073x-00 for ; Mon, 14 Dec 2009 00:26:18 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NJxpR-0005ws-EO for ding@gnus.org; Mon, 14 Dec 2009 00:26:17 +0100 Original-Received: from bas3-london14-1096779738.dsl.bell.ca ([65.95.135.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Dec 2009 00:26:17 +0100 Original-Received: from jdc by bas3-london14-1096779738.dsl.bell.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Dec 2009 00:26:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: bas3-london14-1096779738.dsl.bell.ca User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:D6OuOg3c98t9U0iPfA/afKc5qd4= X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:69284 Archived-At: Dave Love writes: > I don't know from where this was Cc'd, as I only got the Cc address > without a To. Sorry, it's from ding@gnus.org, which I read via gmane.emacs.gnus.general. That might have been put in the Newsgroups header, but I understand why that might have been confusing. This post is the same. > Dan Christensen writes: > >> Here's another patch that I think should be applied. When parsing a >> date, it first tries parse-time-string, and only falls back to using >> timezone-make-date-arpa-standard if parse-time-string gives an error. >> This is about 4 times faster in my tests with good dates, and shaves >> 0.6s off of opening a summary buffer with 6000 articles. I've cc'd >> Dave Love since I believe he introduced this. If he can confirm that >> the problematic dates he encountered triggered an error in >> parse-time-string, then this patch should be ok. > > The comment says that parse-time-string can produce bogus results rather > than fail. I vaguely remember this was about getting silly results from > two-digit dates around the millennium -- returning the epoch, I guess -- > but I don't know for sure. Well, I guess we shouldn't apply the date-to-time patch then, although it would be better if we really knew what the problem was and could fix it without slowing things down by a factor of 4. On the other hand, if the caching patch gets applied, then it shouldn't matter too much in practise. (The 0.6s above is with the caching patch applied; the time difference would be *much* larger without the caching patch.) Dan