From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.devel Subject: Re: simple patch for `etags.el' Date: Wed, 22 Sep 2004 12:04:49 -0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200409221204.49928.pogonyshev@gmx.net> References: <200409201650.26315.pogonyshev@gmx.net> <200409212200.22757.pogonyshev@gmx.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1095844102 28973 80.91.229.6 (22 Sep 2004 09:08:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 22 Sep 2004 09:08:22 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 22 11:08:13 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CA36i-0001Pl-00 for ; Wed, 22 Sep 2004 11:08:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CA3Cg-0006QO-KB for ged-emacs-devel@m.gmane.org; Wed, 22 Sep 2004 05:14:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CA3CO-0006PG-KM for emacs-devel@gnu.org; Wed, 22 Sep 2004 05:14:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CA3CK-0006OX-Hp for emacs-devel@gnu.org; Wed, 22 Sep 2004 05:14:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CA3CI-0006O5-8V for emacs-devel@gnu.org; Wed, 22 Sep 2004 05:13:58 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1CA36D-0004lo-LU for emacs-devel@gnu.org; Wed, 22 Sep 2004 05:07:42 -0400 Original-Received: (qmail 9956 invoked by uid 65534); 22 Sep 2004 09:00:58 -0000 Original-Received: from unknown (EHLO localhost.localdomain) (195.50.12.118) by mail.gmx.net (mp005) with SMTP; 22 Sep 2004 11:00:58 +0200 X-Authenticated: #16844820 Original-To: storm@cua.dk (Kim F. Storm) User-Agent: KMail/1.4.3 In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27424 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27424 > Paul Pogonyshev writes: > > Richard Stallman wrote: > >> Even better, how about not updating the percentage more than once > >> per second? > > > > This turned out not to be better. Overhead caused by time > > fetching and comparisons is not worth the gain. When > > percentage is printed whenever it changes, `message' is > > called at most 101 times and that is cheap. Note that 101 > > is a constant, while the number of constraint evaluations > > is practically not limited. > > You could do the time check only when you are about to call message, > ie. a max of 101 times. No, it is not a max of 101 times. Consider this: TIME=09PERCENTAGE=09SHOWING?=09COMMENT 0.00=090%=09=09YES=09=09now delaying till at least 1% and 0.20 seconds 0.01=090%=09=09NO 0.02=091%=09=09NO=09=09but evaluating time constraint 0.03=091%=09=09NO=09=09--"-- 0.04=091%=09=09NO=09=09--"-- =2E.. In other words it is max of 101 times that time constraint will be evaluated and passed. Number of evaluations that yield nil is virtually no limited. Actually, my patch did just this: =09(when (and (reached-next-percentage) =09=09 (enough-time-has-passed)) but it is slower than just =09(when (reached-next-percentage) > > So I suggest not bothering with time. It is faster, gives > > much simpler code and, finally, once per second is still to > > rarely, at least to my tastes. > > Probably -- but a default period of 0.2 seconds would be ok. It is OK, but slower. I posted two versions of `progress-reporter', first with additional time constraint, the second without. You can try both and see that the second is indeed faster. On tags completion I had something like 2.1 sec with time constraint and 1.5 sec without. Unpatched code runs for at least 5 seconds here (not measured, but it seems so). Paul