From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.devel Subject: Re: Inefficient code in xml.el Date: Mon, 06 Jun 2005 11:18:12 -0600 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1118078819 7498 80.91.229.2 (6 Jun 2005 17:26:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Jun 2005 17:26:59 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 06 19:26:59 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DfLKl-0004XP-KU for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2005 19:24:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfLR7-0005Yq-2Q for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2005 13:30:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DfLOJ-0004ll-MV for emacs-devel@gnu.org; Mon, 06 Jun 2005 13:28:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DfLOB-0004f5-RH for emacs-devel@gnu.org; Mon, 06 Jun 2005 13:27:54 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfLO9-0004UP-Jr for emacs-devel@gnu.org; Mon, 06 Jun 2005 13:27:49 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1DfLKI-0001hg-Q1 for emacs-devel@gnu.org; Mon, 06 Jun 2005 13:23:51 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DfLCV-0003Gg-QL for emacs-devel@gnu.org; Mon, 06 Jun 2005 19:15:47 +0200 Original-Received: from 207.167.42.60 ([207.167.42.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jun 2005 19:15:47 +0200 Original-Received: from ihs_4664 by 207.167.42.60 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jun 2005 19:15:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 50 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 207.167.42.60 User-Agent: Mozilla Thunderbird 0.9 (X11/20041105) X-Accept-Language: en-us, en 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:38196 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38196 klaus.berndl@sdm.de wrote: > Well, i get the point, but how an elisp-programmer should know this?! > > The manual says: > > - Function: match-data > This function returns a newly constructed list containing all the > information on what text the last search matched. Element zero is > the position of the beginning of the match for the whole > expression; element one is the position of the end of the match > for the expression. The next two elements are the positions of > the beginning and end of the match for the first subexpression, > and so on. In general, element number 2N corresponds to > `(match-beginning N)'; and element number 2N + 1 corresponds to > `(match-end N)'. > > All the elements are markers or `nil' if matching was done on a > buffer, and all are integers or `nil' if matching was done on a > string with `string-match'. > > As always, there must be no possibility of intervening searches > between the call to a search function and the call to `match-data' > that is intended to access the match data for that search. > > (match-data) > => (# > # > # > #) > > What about to mention such inefficiency-problems in the documentation?! > The manual only says "... Corresponds to ....". IMHO the documentation > must mention the performnace-topic if it is so important you wrote in > these postings! Just change the first sentence to: This function returns a newly constructed list of newly allocated markers, containing all the information on what text the last search matched. A reference to the Markers node there might be useful. And this bit from the Markers node should be emphasized: Insertion and deletion in a buffer must check all the markers and relocate them if necessary. This slows processing in a buffer with a large number of markers. -- Kevin Rodgers