From unknown Fri Jun 20 07:28:19 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#24012 <24012@debbugs.gnu.org> To: bug#24012 <24012@debbugs.gnu.org> Subject: Status: 25.0.95; forward-comment backwards takes O(n^2) Reply-To: bug#24012 <24012@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:28:19 +0000 retitle 24012 25.0.95; forward-comment backwards takes O(n^2) reassign 24012 emacs submitter 24012 Leo Liu severity 24012 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 17 07:04:51 2016 Received: (at submit) by debbugs.gnu.org; 17 Jul 2016 11:04:52 +0000 Received: from localhost ([127.0.0.1]:54299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOjsQ-0008Pw-Vv for submit@debbugs.gnu.org; Sun, 17 Jul 2016 07:04:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOjsO-0008Pf-0I for submit@debbugs.gnu.org; Sun, 17 Jul 2016 07:04:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOjsF-0001U4-OG for submit@debbugs.gnu.org; Sun, 17 Jul 2016 07:04:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOjsF-0001Tz-L7 for submit@debbugs.gnu.org; Sun, 17 Jul 2016 07:04:39 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOjs9-0001FS-SH for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2016 07:04:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOjs5-0001TG-HQ for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2016 07:04:32 -0400 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:36684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOjs5-0001T3-3Q for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2016 07:04:29 -0400 Received: by mail-wm0-x233.google.com with SMTP id f126so73166171wma.1 for ; Sun, 17 Jul 2016 04:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version; bh=NPUpGcLPsFPndfxAF3acewPDKWQGI2hcCSAcvVk80r8=; b=mnldLJx6Ix/CVpM9BaQMJqJUtxSrwkr2HV/1pK0E/5uXUwfTNGkqi3+8dBAg9G1URJ CPARbfPW07HIx+tyLGrALaZ+Mhdu5A2rct9h5SrFtbybXEYUDM+z4RxS2WHzsU2jaTMt 2bqsuKLFH4yHWs26YVyha3SDA3gz2Hofnga8KN3Zo68A6AvhhkLtMfCV4Ypsq38oM6AH fLT9vPwZ498i/zGKAX2i4n8zPqB1W4yOYqKoH9hdEo5sKNua54or4uhq/I38mm8/3MZ0 N/oprmdWA2x8cXsx0xG4SFLK2aHL6i4jZDwp4qc6bKblh/ltZk0s+Xi8KYUP4fTjO2fx qV0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=NPUpGcLPsFPndfxAF3acewPDKWQGI2hcCSAcvVk80r8=; b=DCwif5TFOmynnN83wSCC650/g6F3HKuTTBGNHKnrt49mmnairh6aQbx/Rn+akKmkYS x5Y3rqvqhKd3OoMylV54yhi8ReZAcGRREipG0pw+rPJroycSwgIknmKJ7Kof1yM4INc8 xaHqvYtCACgZ7alBFlIC5ja+hp5Ft7N3GF4KOBDT+t56jirKw5lvngf5ev8UUW9xu1tB UnyKYzrrvUmySYdZKiNbn2PEHQHK1RUioeLx4LAJsDQr+BWiYNcHoSkPrIdC2qh/z7Kf 89tCra076siDv5aZWiw/5Dxz2uG/b9dp9SwHSviGr8h0A6m6/HAAq/DPddNWJ9h7Xar4 BtKg== X-Gm-Message-State: ALyK8tKUD0g9L/F0hakcHAeDb7J2U1mV12ytjgIHUUUy5+Pfn5wIXNx3cDWkVVz7oO1rZQ== X-Received: by 10.28.225.4 with SMTP id y4mr31322953wmg.98.1468753466816; Sun, 17 Jul 2016 04:04:26 -0700 (PDT) Received: from zeuss-MacBook-Pro.local ([46.101.90.246]) by smtp.gmail.com with ESMTPSA id i195sm8298058wmg.1.2016.07.17.04.04.23 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 17 Jul 2016 04:04:25 -0700 (PDT) From: Leo Liu To: bug-gnu-emacs@gnu.org Subject: 25.0.95; forward-comment backwards takes O(n^2) X-Debbugs-CC: Date: Sun, 17 Jul 2016 19:04:18 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --=-=-= Content-Type: text/plain 1. Use the attached file as an example, open it in emacs in ruby-mode 2. Move point to end of buffer and eval (forward-comment (- (point))) The last step takes about 0.25 seconds on my MacBook 3 GHz Intel Core i7. If you double the lines of comments, the time increase by 4 folds. Any idea why forward-comment backwards is so slow? Leo --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=tt.rb Content-Description: tt.rb ### PropEr is free software: you can redistribute it and/or modify ### it under the terms of the GNU General Public License as published by ### the Free Software Foundation, either version 3 of the License, or ### (at your option) any later version. ### ### PropEr is distributed in the hope that it will be useful, ### but WITHOUT ANY WARRANTY; without even the implied warranty of ### MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ### GNU General Public License for more details. ### ### You should have received a copy of the GNU General Public License ### along with PropEr. If not, see . ### @copyright 2010-2016 Manolis Papadakis, Eirini Arvaniti and Kostis Sagonas ### @version {@version} ### @author Eirini Arvaniti ### @doc This module defines the `proper_fsm' behaviour, useful for testing ### systems that can be modeled as finite state machines. That is, a finite ### collection of named states and transitions between them. `{@module}' is ### closely related to {@link proper_statem} and is, in fact, implemented in ### terms of that. Testcases generated using `{@module}' will be on precisely ### the same form as testcases generated using {@link proper_statem}. The ### difference lies in the way the callback modules are specified. ### The relation between {@link proper_statem} and `{@module}' is similar ### to the one between `gen_server' and `gen_fsm' in OTP libraries. ### ### Due to name conflicts with functions automatically imported from ### {@link proper_statem}, a fully qualified call is needed in order to ### use the API functions of `{@module}'. ### ### === The states of the finite state machine === ### Following the convention used in `gen_fsm behaviour', the state is ### separated into a `StateName::'{@type state_name()} and some ### `StateData::'{@type state_data()}. `StateName' is used to denote a state ### of the finite state machine and `StateData' is any relevant information ### that has to be stored in the model state. States are fully ### represented as tuples `{StateName, StateData}'. ### ### `StateName' is usually an atom (i.e. the name of the state), but can also ### be a tuple. In the latter case, the first element of the tuple must be an ### atom specifying the name of the state, whereas the rest of the elements can ### be arbitrary terms specifying state attributes. For example, when ### implementing the fsm of an elevator which can reach N different floors, the ### `StateName' for each floor could be `{floor,K}, 1 <= K <= N'.
### `StateData' can be an arbitrary term, but is usually a record. ### ### === Transitions between states === ### A transition ({@type transition()}) is represented as a tuple ### `{TargetState, {call,M,F,A}}'. This means that performing the specified ### symbolic call at the current state of the fsm will lead to `TargetState'. ### The atom `history' can be used as `TargetState' to denote that a transition ### does not change the current state of the fsm. ### ### === The callback functions === ### The following functions must be exported from the callback module ### implementing the finite state machine: ###
    ###
  • `initial_state() ->' {@type state_name()} ###

    Specifies the initial state of the finite state machine. As with ### `proper_statem:initial_state/0', its result should be deterministic. ###

    • ###
  • `initial_state_data() ::' {@type state_data()} ###

    Specifies what the state data should initially contain. Its result ### should be deterministic

    • ###
  • `StateName(S::'{@type state_data()}`) ::' ### `['{@type transition()}`]' ###

    There should be one instance of this function for each reachable ### state `StateName' of the finite state machine. In case `StateName' is a ### tuple the function takes a different form, described just below. The ### function returns a list of possible transitions ({@type transition()}) ### from the current state. ### At command generation time, the instance of this function with the same ### name as the current state's name is called to return the list of possible ### transitions. Then, PropEr will randomly choose a transition and, ### according to that, generate the next symbolic call to be included in the ### command sequence. However, before the call is actually included, a ### precondition that might impose constraints on `StateData' is checked.
    ### Note also that PropEr detects transitions that would raise an exception ### of class `' at generation time (not earlier) and does not choose ### them. This feature can be used to include conditional transitions that ### depend on the `StateData'.

    • ###
  • `StateName(Attr1::term(), ..., AttrN::term(), ### S::'{@type state_data()}`) ::' ### `['{@type transition()}`]' ###

    There should be one instance of this function for each reachable state ### `{StateName,Attr1,...,AttrN}' of the finite state machine. The function ### has similar beaviour to `StateName/1', described above.

    • ###
  • `weight(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### Call::'{@type symbolic_call()}`) -> integer()' ###

    This is an optional callback. When it is not defined (or not exported), ### transitions are chosen with equal probability. When it is defined, it ### assigns an integer weight to transitions from `From' to `Target' ### triggered by symbolic call `Call'. In this case, each transition is chosen ### with probability proportional to the weight assigned.

    • ###
  • `precondition(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Call::'{@type symbolic_call()}`) -> boolean()' ###

    Similar to `proper_statem:precondition/2'. Specifies the ### precondition that should hold about `StateData' so that `Call' can be ### included in the command sequence. In case precondition doesn't hold, a ### new transition is chosen using the appropriate `StateName/1' generator. ### It is possible for more than one transitions to be triggered by the same ### symbolic call and lead to different target states. In this case, at most ### one of the target states may have a true precondition. Otherwise, PropEr ### will not be able to detect which transition was chosen and an exception ### will be raised.

    • ###
  • `postcondition(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Call::'{@type symbolic_call()}`, ### Res::'{@type cmd_result()}`) -> boolean()' ###

    Similar to `proper_statem:postcondition/3'. Specifies the ### postcondition that should hold about the result `Res' of the evaluation ### of `Call'.

    • ###
  • `next_state_data(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Res::'{@type cmd_result()}`, ### Call::'{@type symbolic_call()}`) ->' ### {@type state_data()} ###

    Similar to `proper_statem:next_state/3'. Specifies how the ### transition from `FromState' to `Target' triggered by `Call' affects the ### `StateData'. `Res' refers to the result of `Call' and can be either ### symbolic or dynamic.

    • ###
### ### === The property used === ### This is an example of a property that can be used to test a ### finite state machine specification: ### ### ```prop_fsm() -> ### ?FORALL(Cmds, proper_fsm:commands(?MODULE), ### begin ### {_History, _State, Result} = proper_fsm:run_commands(?MODULE, Cmds), ### cleanup(), ### Result =:= ok ### end).''' ### @end ### Copyright 2010-2016 Manolis Papadakis , ### Eirini Arvaniti ### and Kostis Sagonas ### ### This file is part of PropEr. ### ### PropEr is free software: you can redistribute it and/or modify ### it under the terms of the GNU General Public License as published by ### the Free Software Foundation, either version 3 of the License, or ### (at your option) any later version. ### ### PropEr is distributed in the hope that it will be useful, ### but WITHOUT ANY WARRANTY; without even the implied warranty of ### MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ### GNU General Public License for more details. ### ### You should have received a copy of the GNU General Public License ### along with PropEr. If not, see . ### @copyright 2010-2016 Manolis Papadakis, Eirini Arvaniti and Kostis Sagonas ### @version {@version} ### @author Eirini Arvaniti ### @doc This module defines the `proper_fsm' behaviour, useful for testing ### systems that can be modeled as finite state machines. That is, a finite ### collection of named states and transitions between them. `{@module}' is ### closely related to {@link proper_statem} and is, in fact, implemented in ### terms of that. Testcases generated using `{@module}' will be on precisely ### the same form as testcases generated using {@link proper_statem}. The ### difference lies in the way the callback modules are specified. ### The relation between {@link proper_statem} and `{@module}' is similar ### to the one between `gen_server' and `gen_fsm' in OTP libraries. ### ### Due to name conflicts with functions automatically imported from ### {@link proper_statem}, a fully qualified call is needed in order to ### use the API functions of `{@module}'. ### ### === The states of the finite state machine === ### Following the convention used in `gen_fsm behaviour', the state is ### separated into a `StateName::'{@type state_name()} and some ### `StateData::'{@type state_data()}. `StateName' is used to denote a state ### of the finite state machine and `StateData' is any relevant information ### that has to be stored in the model state. States are fully ### represented as tuples `{StateName, StateData}'. ### ### `StateName' is usually an atom (i.e. the name of the state), but can also ### be a tuple. In the latter case, the first element of the tuple must be an ### atom specifying the name of the state, whereas the rest of the elements can ### be arbitrary terms specifying state attributes. For example, when ### implementing the fsm of an elevator which can reach N different floors, the ### `StateName' for each floor could be `{floor,K}, 1 <= K <= N'.
### `StateData' can be an arbitrary term, but is usually a record. ### ### === Transitions between states === ### A transition ({@type transition()}) is represented as a tuple ### `{TargetState, {call,M,F,A}}'. This means that performing the specified ### symbolic call at the current state of the fsm will lead to `TargetState'. ### The atom `history' can be used as `TargetState' to denote that a transition ### does not change the current state of the fsm. ### ### === The callback functions === ### The following functions must be exported from the callback module ### implementing the finite state machine: ###
    ###
  • `initial_state() ->' {@type state_name()} ###

    Specifies the initial state of the finite state machine. As with ### `proper_statem:initial_state/0', its result should be deterministic. ###

    • ###
  • `initial_state_data() ::' {@type state_data()} ###

    Specifies what the state data should initially contain. Its result ### should be deterministic

    • ###
  • `StateName(S::'{@type state_data()}`) ::' ### `['{@type transition()}`]' ###

    There should be one instance of this function for each reachable ### state `StateName' of the finite state machine. In case `StateName' is a ### tuple the function takes a different form, described just below. The ### function returns a list of possible transitions ({@type transition()}) ### from the current state. ### At command generation time, the instance of this function with the same ### name as the current state's name is called to return the list of possible ### transitions. Then, PropEr will randomly choose a transition and, ### according to that, generate the next symbolic call to be included in the ### command sequence. However, before the call is actually included, a ### precondition that might impose constraints on `StateData' is checked.
    ### Note also that PropEr detects transitions that would raise an exception ### of class `' at generation time (not earlier) and does not choose ### them. This feature can be used to include conditional transitions that ### depend on the `StateData'.

    • ###
  • `StateName(Attr1::term(), ..., AttrN::term(), ### S::'{@type state_data()}`) ::' ### `['{@type transition()}`]' ###

    There should be one instance of this function for each reachable state ### `{StateName,Attr1,...,AttrN}' of the finite state machine. The function ### has similar beaviour to `StateName/1', described above.

    • ###
  • `weight(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### Call::'{@type symbolic_call()}`) -> integer()' ###

    This is an optional callback. When it is not defined (or not exported), ### transitions are chosen with equal probability. When it is defined, it ### assigns an integer weight to transitions from `From' to `Target' ### triggered by symbolic call `Call'. In this case, each transition is chosen ### with probability proportional to the weight assigned.

    • ###
  • `precondition(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Call::'{@type symbolic_call()}`) -> boolean()' ###

    Similar to `proper_statem:precondition/2'. Specifies the ### precondition that should hold about `StateData' so that `Call' can be ### included in the command sequence. In case precondition doesn't hold, a ### new transition is chosen using the appropriate `StateName/1' generator. ### It is possible for more than one transitions to be triggered by the same ### symbolic call and lead to different target states. In this case, at most ### one of the target states may have a true precondition. Otherwise, PropEr ### will not be able to detect which transition was chosen and an exception ### will be raised.

    • ###
  • `postcondition(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Call::'{@type symbolic_call()}`, ### Res::'{@type cmd_result()}`) -> boolean()' ###

    Similar to `proper_statem:postcondition/3'. Specifies the ### postcondition that should hold about the result `Res' of the evaluation ### of `Call'.

    • ###
  • `next_state_data(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Res::'{@type cmd_result()}`, ### Call::'{@type symbolic_call()}`) ->' ### {@type state_data()} ###

    Similar to `proper_statem:next_state/3'. Specifies how the ### transition from `FromState' to `Target' triggered by `Call' affects the ### `StateData'. `Res' refers to the result of `Call' and can be either ### symbolic or dynamic.

    • ###
### ### === The property used === ### This is an example of a property that can be used to test a ### finite state machine specification: ### ### ```prop_fsm() -> ### ?FORALL(Cmds, proper_fsm:commands(?MODULE), ### begin ### {_History, _State, Result} = proper_fsm:run_commands(?MODULE, Cmds), ### cleanup(), ### Result =:= ok ### end).''' ### @end ### Copyright 2010-2016 Manolis Papadakis , ### Eirini Arvaniti ### and Kostis Sagonas ### ### This file is part of PropEr. ### ### PropEr is free software: you can redistribute it and/or modify ### it under the terms of the GNU General Public License as published by ### the Free Software Foundation, either version 3 of the License, or ### (at your option) any later version. ### ### PropEr is distributed in the hope that it will be useful, ### but WITHOUT ANY WARRANTY; without even the implied warranty of ### MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ### GNU General Public License for more details. ### ### You should have received a copy of the GNU General Public License ### along with PropEr. If not, see . ### @copyright 2010-2016 Manolis Papadakis, Eirini Arvaniti and Kostis Sagonas ### @version {@version} ### @author Eirini Arvaniti ### @doc This module defines the `proper_fsm' behaviour, useful for testing ### systems that can be modeled as finite state machines. That is, a finite ### collection of named states and transitions between them. `{@module}' is ### closely related to {@link proper_statem} and is, in fact, implemented in ### terms of that. Testcases generated using `{@module}' will be on precisely ### the same form as testcases generated using {@link proper_statem}. The ### difference lies in the way the callback modules are specified. ### The relation between {@link proper_statem} and `{@module}' is similar ### to the one between `gen_server' and `gen_fsm' in OTP libraries. ### ### Due to name conflicts with functions automatically imported from ### {@link proper_statem}, a fully qualified call is needed in order to ### use the API functions of `{@module}'. ### ### === The states of the finite state machine === ### Following the convention used in `gen_fsm behaviour', the state is ### separated into a `StateName::'{@type state_name()} and some ### `StateData::'{@type state_data()}. `StateName' is used to denote a state ### of the finite state machine and `StateData' is any relevant information ### that has to be stored in the model state. States are fully ### represented as tuples `{StateName, StateData}'. ### ### `StateName' is usually an atom (i.e. the name of the state), but can also ### be a tuple. In the latter case, the first element of the tuple must be an ### atom specifying the name of the state, whereas the rest of the elements can ### be arbitrary terms specifying state attributes. For example, when ### implementing the fsm of an elevator which can reach N different floors, the ### `StateName' for each floor could be `{floor,K}, 1 <= K <= N'.
### `StateData' can be an arbitrary term, but is usually a record. ### ### === Transitions between states === ### A transition ({@type transition()}) is represented as a tuple ### `{TargetState, {call,M,F,A}}'. This means that performing the specified ### symbolic call at the current state of the fsm will lead to `TargetState'. ### The atom `history' can be used as `TargetState' to denote that a transition ### does not change the current state of the fsm. ### ### === The callback functions === ### The following functions must be exported from the callback module ### implementing the finite state machine: ###
    ###
  • `initial_state() ->' {@type state_name()} ###

    Specifies the initial state of the finite state machine. As with ### `proper_statem:initial_state/0', its result should be deterministic. ###

    • ###
  • `initial_state_data() ::' {@type state_data()} ###

    Specifies what the state data should initially contain. Its result ### should be deterministic

    • ###
  • `StateName(S::'{@type state_data()}`) ::' ### `['{@type transition()}`]' ###

    There should be one instance of this function for each reachable ### state `StateName' of the finite state machine. In case `StateName' is a ### tuple the function takes a different form, described just below. The ### function returns a list of possible transitions ({@type transition()}) ### from the current state. ### At command generation time, the instance of this function with the same ### name as the current state's name is called to return the list of possible ### transitions. Then, PropEr will randomly choose a transition and, ### according to that, generate the next symbolic call to be included in the ### command sequence. However, before the call is actually included, a ### precondition that might impose constraints on `StateData' is checked.
    ### Note also that PropEr detects transitions that would raise an exception ### of class `' at generation time (not earlier) and does not choose ### them. This feature can be used to include conditional transitions that ### depend on the `StateData'.

    • ###
  • `StateName(Attr1::term(), ..., AttrN::term(), ### S::'{@type state_data()}`) ::' ### `['{@type transition()}`]' ###

    There should be one instance of this function for each reachable state ### `{StateName,Attr1,...,AttrN}' of the finite state machine. The function ### has similar beaviour to `StateName/1', described above.

    • ###
  • `weight(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### Call::'{@type symbolic_call()}`) -> integer()' ###

    This is an optional callback. When it is not defined (or not exported), ### transitions are chosen with equal probability. When it is defined, it ### assigns an integer weight to transitions from `From' to `Target' ### triggered by symbolic call `Call'. In this case, each transition is chosen ### with probability proportional to the weight assigned.

    • ###
  • `precondition(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Call::'{@type symbolic_call()}`) -> boolean()' ###

    Similar to `proper_statem:precondition/2'. Specifies the ### precondition that should hold about `StateData' so that `Call' can be ### included in the command sequence. In case precondition doesn't hold, a ### new transition is chosen using the appropriate `StateName/1' generator. ### It is possible for more than one transitions to be triggered by the same ### symbolic call and lead to different target states. In this case, at most ### one of the target states may have a true precondition. Otherwise, PropEr ### will not be able to detect which transition was chosen and an exception ### will be raised.

    • ###
  • `postcondition(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Call::'{@type symbolic_call()}`, ### Res::'{@type cmd_result()}`) -> boolean()' ###

    Similar to `proper_statem:postcondition/3'. Specifies the ### postcondition that should hold about the result `Res' of the evaluation ### of `Call'.

    • ###
  • `next_state_data(From::'{@type state_name()}`, ### Target::'{@type state_name()}`, ### StateData::'{@type state_data()}`, ### Res::'{@type cmd_result()}`, ### Call::'{@type symbolic_call()}`) ->' ### {@type state_data()} ###

    Similar to `proper_statem:next_state/3'. Specifies how the ### transition from `FromState' to `Target' triggered by `Call' affects the ### `StateData'. `Res' refers to the result of `Call' and can be either ### symbolic or dynamic.

    • ###
### ### === The property used === ### This is an example of a property that can be used to test a ### finite state machine specification: ### ### ```prop_fsm() -> ### ?FORALL(Cmds, proper_fsm:commands(?MODULE), ### begin ### {_History, _State, Result} = proper_fsm:run_commands(?MODULE, Cmds), ### cleanup(), ### Result =:= ok ### end).''' ### @end --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 17 08:12:20 2016 Received: (at 24012) by debbugs.gnu.org; 17 Jul 2016 12:12:20 +0000 Received: from localhost ([127.0.0.1]:54324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOkvk-00037J-9Q for submit@debbugs.gnu.org; Sun, 17 Jul 2016 08:12:20 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOkvi-000376-Gn for 24012@debbugs.gnu.org; Sun, 17 Jul 2016 08:12:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOkva-0004Y9-AO for 24012@debbugs.gnu.org; Sun, 17 Jul 2016 08:12:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOkva-0004Xu-7N; Sun, 17 Jul 2016 08:12:10 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1939 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bOkvY-0005Hv-8F; Sun, 17 Jul 2016 08:12:08 -0400 Date: Sun, 17 Jul 2016 15:12:01 +0300 Message-Id: <83poqc4g6m.fsf@gnu.org> From: Eli Zaretskii To: Leo Liu In-reply-to: (message from Leo Liu on Sun, 17 Jul 2016 19:04:18 +0800) Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 24012 Cc: 24012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Leo Liu > Date: Sun, 17 Jul 2016 19:04:18 +0800 > > 1. Use the attached file as an example, open it in emacs in ruby-mode > 2. Move point to end of buffer and eval (forward-comment (- (point))) > > The last step takes about 0.25 seconds on my MacBook 3 GHz Intel Core > i7. If you double the lines of comments, the time increase by 4 folds. > > Any idea why forward-comment backwards is so slow? Because search functions cannot really search backwards? From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 17 09:34:22 2016 Received: (at submit) by debbugs.gnu.org; 17 Jul 2016 13:34:22 +0000 Received: from localhost ([127.0.0.1]:54365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOmD8-000522-JN for submit@debbugs.gnu.org; Sun, 17 Jul 2016 09:34:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36903) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOmD7-00051q-C6 for submit@debbugs.gnu.org; Sun, 17 Jul 2016 09:34:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOmD1-0002fs-EO for submit@debbugs.gnu.org; Sun, 17 Jul 2016 09:34:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:44062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOmD1-0002fh-Bl for submit@debbugs.gnu.org; Sun, 17 Jul 2016 09:34:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOmCz-0000R1-Dq for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2016 09:34:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOmCt-0002f4-Dj for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2016 09:34:12 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:57960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOmCt-0002et-3G for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2016 09:34:07 -0400 Received: from [192.168.178.35] ([95.119.235.69]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MdWxQ-1bjky90Saq-00PL11 for ; Sun, 17 Jul 2016 15:34:05 +0200 Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) To: bug-gnu-emacs@gnu.org References: From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Message-ID: Date: Sun, 17 Jul 2016 15:39:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4TRnm90QeqSJreOzI7mNeMrFHyWsS4iR0zOZLTa6+F1xVp0z6pS 1jMXUdIJik+aqfquvLH48JoRI2XIg9xy3qzhxq+NMwB6Jxqnj325YYXH/c8nXrGWi34lfrf +gbcehd0nbS2yeRjnMIz3TJoO2WCKgO7zJagLyOaA3T5BWrRTTFTkpCnYqpUpPlYwzaBM38 CsStl4fLYdsJxH6sHFpqw== X-UI-Out-Filterresults: notjunk:1;V01:K0:RGibobgM/6E=:gqYKTaJtkb2ERKB7ESu5Jr I1Hf4UdvMjM3NDyEgAyCFsWL0SpCB4YRze7ZoCdtQFtDReYsVCts4/X1HxhgybHPHlBVl0E4k 8L14qswHpVUUACXsLHT3cwM1ejgQH53ATmWzk0D9qgQfOMwWgYWEu/lJYDfMt4QQGEIRSK/fe Mpy6sL4l38K2BPrqDWhKKMdeWJ3sU1pKmI84I78e1pWs47Z+RR20Mpong6xvm5YBi44KyYAJC Dk12YalCniIp/i/o/gryO4ap6ITJ7j+6SqOG1SBiJEw7SOqbLfwSjnXgGp3dDllim7BdNgpU3 oB6m2rndEORL/p1uL//ONG6xe00CumloB5P4Bxe7BnFEJqV4L+Z+gwD/RstPr0+I5YPnUzc5R 1D4WK6awUWC2Ub2FiHSiU4keNmpvURO1zqtsWc+xpu0Num9tOFA18IGnwhujv+fKRWsaK75HX EhCDDer2Hb45j96lzBSoaZwl9xW3QaLfK6s6ll0h7cpJ1MNc+5qEErpo40Yqt1m96F95hvQJb uF1kw0xGmP3xgOcrPrzKT/d/WMT1KKt5AYseNPqBIJPNxOCrtLrFgNHdm9qhUkHiq/9a6GOrf s28LtbXwqijf8nkRLjfodmBNvtCy7agIbCwXHTXBEdbTxidcBTHDZ204dQEQnJYNNTPZhwi6R AN0i6z6GVICW3SeULGmOmMxcI3DqjIdS6gn95cFRV0643DNcZ5SAiAjvPlSuueGJBqT1HJdFp ly78FH3wO+LP16Xb X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 17.07.2016 13:04, Leo Liu wrote: > 1. Use the attached file as an example, open it in emacs in ruby-mode > 2. Move point to end of buffer and eval (forward-comment (- (point))) > > The last step takes about 0.25 seconds on my MacBook 3 GHz Intel Core > i7. If you double the lines of comments, the time increase by 4 folds. > > Any idea why forward-comment backwards is so slow? > > Leo > With last line ### @end (forward-comment (- (point))) evaluation last expression doesn't move backward at all, returns nil GNU Emacs 25.0.95.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-06-12 From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 17 20:15:58 2016 Received: (at 24012) by debbugs.gnu.org; 18 Jul 2016 00:15:58 +0000 Received: from localhost ([127.0.0.1]:54925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOwE2-00012C-NN for submit@debbugs.gnu.org; Sun, 17 Jul 2016 20:15:58 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:34579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOwE1-00011z-DM for 24012@debbugs.gnu.org; Sun, 17 Jul 2016 20:15:57 -0400 Received: by mail-wm0-f49.google.com with SMTP id q128so8623100wma.1 for <24012@debbugs.gnu.org>; Sun, 17 Jul 2016 17:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version; bh=6Uah0KYKpU75tkoLM2c0h4dLPtFQsQYkTEQ2s5uwET0=; b=JqDRw7W76eS1KUHJEZWGs110Hft8PnFHbDN/38OU4lwDO2tnsJnqzx2WK8dE14kZmW xbKlBuqksK/MaOM67GZUKjo94/1J3Qm9UiSrV+9LquTlNJb1hvL+kGvoWPx+JRb8zulu GDfPqU4stX48nfqHUrTZ/TcZAV+E/XFK6yZ5Ayj8GsZilAeBRSmk+SQ0G03iANkEdA/R cpdbLvLdLNN3fiQ3MQd/Skb5GF/MzAGTG7OuC7QnOY6JNN3wvQfRzNdIsdeo+sLp0vPb 0XeSdCQCGap9umA2HR3lM0hPyE8kpYVegATWJvW7J1ZQ38s92FT8ZT53Kr8hc17xrWUV Z1tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:face:date :in-reply-to:message-id:user-agent:mime-version; bh=6Uah0KYKpU75tkoLM2c0h4dLPtFQsQYkTEQ2s5uwET0=; b=jlKux3yw+yCkLOOJ3a8zke1S76dsrC/DReTOwg2mm48lA+11zIIgrZp/J1zUsi0V5f aIeqxOUScoJZP4Sn/deY/L7bOEcNxm9N1LHssSmVBQrAWokDVLHBrUH5J3v1aXP75tcy bQLVj5fUQbmXpMqSCBID5GMcwnNZVT6a8FiZKwxFBXKQT7OU4B6pd6B3q2fti0dKNycI LuQoWVfTtcf1I1Cdv0dxZ5uGBdd2k89qiQ6pYDpAXGFVqOP4adGA6J7zq5KilAipzktf 3CYR6igGIpI2ZjT08gjLYVCiaA9sqGRg3e2DPjjlmb+pBMm4S25yrbgZtrLyBeup42IL aXhw== X-Gm-Message-State: ALyK8tL2vjz66ICxqsu4SJyOt/Wpaewdg9xKQu/o7vye6oMcleLtA+Jb5yqZt2OPPOe/TQ== X-Received: by 10.28.191.193 with SMTP id o62mr48058560wmi.64.1468800951499; Sun, 17 Jul 2016 17:15:51 -0700 (PDT) Received: from zeuss-MacBook-Pro.local ([46.101.90.246]) by smtp.gmail.com with ESMTPSA id v134sm12446078wmf.10.2016.07.17.17.15.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 17 Jul 2016 17:15:50 -0700 (PDT) From: Leo Liu To: Eli Zaretskii Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) References: <83poqc4g6m.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAACkAAAApAQAAAACAGz1bAAABKElEQVQYlWNg3NIt5FDPUPt7 4+X79Qyucz5/ugik+L2PBgKpyphaIK921q23QDnG0NBQoMr/vaWl9f8ZLL78uPv5PwN7RETfzXoG jhmFz27XM0RXmpuY/WfY+fv0Mc56BvFybfXA/wwL5t/wF61n2PU59axXPcOVzbmSW/8zrNt1benC /ww70hqUU/4zKCtrT9jwn8FhwynbufUMendE2aLqGRpdX9al1zM8eh17lKeeQcTMrdD5P8P3j/YT Q/8zXHSb7p1Qz/C4OM2JuZ7hgtI7K6AjqsMnf8j4z8C6xG1tw3+GqpqvsVn/GTzmpD9j/8/wP/oZ S/l/Bka+QO/g/wy15ueeFQL9N1O8mPU/g+umV3t1gdT0/1bTgHLqYVeXAlWKpMWt+w8Az82C9nHf X0cAAAAASUVORK5CYII= Date: Mon, 18 Jul 2016 08:15:44 +0800 In-Reply-To: <83poqc4g6m.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 17 Jul 2016 15:12:01 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (OS X 10.11.5) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24012 Cc: 24012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2016-07-17 15:12 +0300, Eli Zaretskii wrote: > Because search functions cannot really search backwards? But by changing the major mode to octave-mode you get a 12 times speedup without doing anything. Leo From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 17 22:36:26 2016 Received: (at 24012) by debbugs.gnu.org; 18 Jul 2016 02:36:26 +0000 Received: from localhost ([127.0.0.1]:54964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOyPx-0005wB-Of for submit@debbugs.gnu.org; Sun, 17 Jul 2016 22:36:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOyPw-0005vz-DM for 24012@debbugs.gnu.org; Sun, 17 Jul 2016 22:36:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bOyPl-0001Mh-UN for 24012@debbugs.gnu.org; Sun, 17 Jul 2016 22:36:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bOyPl-0001MV-RH; Sun, 17 Jul 2016 22:36:13 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2312 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bOyPk-0006FH-1G; Sun, 17 Jul 2016 22:36:12 -0400 Date: Mon, 18 Jul 2016 05:36:10 +0300 Message-Id: <83zipf1xlx.fsf@gnu.org> From: Eli Zaretskii To: Leo Liu In-reply-to: (message from Leo Liu on Mon, 18 Jul 2016 08:15:44 +0800) Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) References: <83poqc4g6m.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 24012 Cc: 24012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Leo Liu > Cc: 24012@debbugs.gnu.org > Date: Mon, 18 Jul 2016 08:15:44 +0800 > > On 2016-07-17 15:12 +0300, Eli Zaretskii wrote: > > Because search functions cannot really search backwards? > > But by changing the major mode to octave-mode you get a 12 times speedup > without doing anything. Profile it. One guess is that the different comment syntax somehow causes this. But that's a guess. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 17 23:05:50 2016 Received: (at 24012) by debbugs.gnu.org; 18 Jul 2016 03:05:50 +0000 Received: from localhost ([127.0.0.1]:54973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOysQ-0006gW-J5 for submit@debbugs.gnu.org; Sun, 17 Jul 2016 23:05:50 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:37644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOysP-0006gE-2S for 24012@debbugs.gnu.org; Sun, 17 Jul 2016 23:05:49 -0400 Received: by mail-wm0-f53.google.com with SMTP id i5so97099441wmg.0 for <24012@debbugs.gnu.org>; Sun, 17 Jul 2016 20:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:message-id:mime-version; bh=e1/V6ViQ8FlxDJTySiMAc7DPUZaDHqQ+AWFOyg70RzM=; b=yYNCQziwARAr+EEcuYQH8iS9YyABJZTZ7gWrR96a8lhOVI18n5JNocMXIY83IBDSgd Usu6FVWaYAs3y0FWiGzbqCJ+E+2u/Ya4W+3qoVmXlPff1PU0jOELZ9Rq3Y+LtXLcZncj FjgUU+RuwVt0vcOM3nvSTZpVERPt0TkAXKUHsuCnuN65O02em5SpTyFuUwBPwh7PNBOG G2uXGiVT1YbXktlKrnUEcCn0QeYwLkbGyP6peNx0aPu4buvdsXmpVRIzlFTAGXxaW609 F/FE0u9GGDTlv5eQcrn1L+dVR6Uz0xR5kdwbjXvB1ZKbHHT1UxFTkR7Jzzwnt9N/zhKV zn3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:face:date :message-id:mime-version; bh=e1/V6ViQ8FlxDJTySiMAc7DPUZaDHqQ+AWFOyg70RzM=; b=mTDUNWrzXNQpLjoqWI0xaUnITxtj8phZHr4P2MdNEl0xLUOFHZuKskpc0pE9tEiMpd ZcG6twvoUKcH/+Yu+LU/tu0nT+aSR+lkoHDa9EQjD1o7YEYKfBGjhcSimnSZ2i8H/6k4 B3dtmE+yvkwXi7Baoeu0sg7h966xicATcbqPPafonDxTApKo594KpgfcO/HrQG+74Qfw TzO49/S5iDkxCaKoZX6I/lFbKOlAj2Ny2XJWbZ6mQlHImI+37C8mHlhA7XRxwFjGVS9Q 7H4yyOOuEF1a7u2w5WkvwZmPJUhQLs3+RUkphYUfDPX2QbBl8/ZUjF4gZHr05MUjoHO/ bunw== X-Gm-Message-State: ALyK8tJDcw47RoGxgfgcyyxRqvpX8Xn8siNASJNjk9wsGU5bBjQ790E6A1rmJvn5B6kNqg== X-Received: by 10.28.44.131 with SMTP id s125mr33422504wms.61.1468811143351; Sun, 17 Jul 2016 20:05:43 -0700 (PDT) Received: from Zeuss-MacBook.local ([46.101.90.246]) by smtp.gmail.com with ESMTPSA id p83sm13255944wma.18.2016.07.17.20.05.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 17 Jul 2016 20:05:42 -0700 (PDT) From: Leo Liu To: Eli Zaretskii Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) References: <83poqc4g6m.fsf@gnu.org> <83zipf1xlx.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoAgMAAADxkFD+AAAADFBMVEUvT09qWs3/pQD///+J kUVcAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9cBBwMLOd3veKQA AACuSURBVBjTldE9CgIxEAXgB+lEyFUC2wo5ikdZ8DSypxhMY7H9VuIVwlqkGRgnm59VsHGafIQ3 CZlAtmKIRaHETgYa12lqvEsPYKf8wXHsPGfqPaUM0g9aJPKFXkmNQmSDqwzz4Fpgpz+6WAPY2z5o uPJJpu0uypcl4nyCibMLQ8lCiVjayLoQvw5LsVKQuHPRR958HZbOcVsKeepcLxpByjycGvnKmY+c MBvrtyjfe0vmuLvdq/kAAAAASUVORK5CYII= Date: Mon, 18 Jul 2016 11:05:01 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24012 Cc: 24012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2016-07-18 05:36 +0300, Eli Zaretskii wrote: > Profile it. One guess is that the different comment syntax somehow > causes this. But that's a guess. How to profile it? Before reporting this bug I have been trying profiler and elp and came to the conclusion that forward-comment was the issue. How do you go further than forward-comment which is in C which I only have limited experience with? Leo From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 18 10:34:45 2016 Received: (at 24012) by debbugs.gnu.org; 18 Jul 2016 14:34:45 +0000 Received: from localhost ([127.0.0.1]:55875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bP9d7-00084y-F3 for submit@debbugs.gnu.org; Mon, 18 Jul 2016 10:34:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bP9d5-00084j-MK for 24012@debbugs.gnu.org; Mon, 18 Jul 2016 10:34:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bP9cw-00070l-Lc for 24012@debbugs.gnu.org; Mon, 18 Jul 2016 10:34:38 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bP9cw-00070e-IK; Mon, 18 Jul 2016 10:34:34 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2668 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bP9cu-0000SG-T6; Mon, 18 Jul 2016 10:34:33 -0400 Date: Mon, 18 Jul 2016 17:34:32 +0300 Message-Id: <83vb0310cn.fsf@gnu.org> From: Eli Zaretskii To: Leo Liu In-reply-to: (message from Leo Liu on Mon, 18 Jul 2016 11:05:01 +0800) Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) References: <83poqc4g6m.fsf@gnu.org> <83zipf1xlx.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 24012 Cc: 24012@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Leo Liu > Cc: 24012@debbugs.gnu.org > Date: Mon, 18 Jul 2016 11:05:01 +0800 > > On 2016-07-18 05:36 +0300, Eli Zaretskii wrote: > > Profile it. One guess is that the different comment syntax somehow > > causes this. But that's a guess. > > How to profile it? > > Before reporting this bug I have been trying profiler and elp and came > to the conclusion that forward-comment was the issue. How do you go > further than forward-comment which is in C which I only have limited > experience with? I meant a comparative profile between the two major modes. As for profiling primitives, there's 'prof' that can make wonders, if you are using a platform which it supports. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 25 10:24:50 2017 Received: (at 24012) by debbugs.gnu.org; 25 Dec 2017 15:24:50 +0000 Received: from localhost ([127.0.0.1]:51957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTUcT-0004S0-Rc for submit@debbugs.gnu.org; Mon, 25 Dec 2017 10:24:50 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:42716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTUcS-0004Rn-NQ for 24012@debbugs.gnu.org; Mon, 25 Dec 2017 10:24:49 -0500 Received: by mail-wm0-f52.google.com with SMTP id b199so32306824wme.1 for <24012@debbugs.gnu.org>; Mon, 25 Dec 2017 07:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8YUM7xTE91uOfgLhXEVGL1xDYdAvxrmD2gGZtPmU01U=; b=VFcvI4XR6G7DVu0IuXvzAHYHyhaWfcROMXAwjYmZcuRztCnJbrAQdLtSwfFkCUnE7k 8n0YcQPvO/5A4Kqt2aSI3mEqYZSvjsTQ1WoKXc7btT0Z6C/U7CeTYcT6ANNhRvUdxHCu H7fi2ZH4uw///GkZggYcnUTdNZaHfsK77U24P0DNQ9ns3f/ZfBsXEVp97zNepPP64NhW lF9TzOJUEeDVHGNIE/QG49XqhavGz72MBUpjJUERc3p0WtV/uWMFLGaakU1DuvsZyrPD b0MSL+tFU9qUgGGlpJIIGEcXCgBfbZKpYlwPxrAKOzp3WmnK4tiaiE6oejl/o0hAhsla tYHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8YUM7xTE91uOfgLhXEVGL1xDYdAvxrmD2gGZtPmU01U=; b=g2oiAp13nXKoiEQB8VQqhUjuhHUVFUqLaCNUYzPr3TuWZgpsT4XANKYp3N4/rCTaJm JSaygaJ5YeKWhp77YCgvlRdyi+Qo+KhZ3oAw18TzfTmtJnOGSJACKGECiVAQo7PLr43f K2Ra4aRVEuvcNZhNbgkCyZ6AeE2T1mITjy2SFtKMNd9zux9wTR0oJx+CAL+ssopS16S+ 93miyrdRG5Bj9CVaRFYK8AZTlrMPdiYeSbh2/RaJzD8m3OQseG2ulQeNxmrrww4auUd8 5SUuHejQluTTGKwoSqvDZHT8tk/flGccdU5pyWsl58pv6bEzMnrubYqnOenIOYuOp90y 52fA== X-Gm-Message-State: AKGB3mKiiQHH32mr5dZgFWfRXzwRfmk6uOx070qLY17JVBvc2FNnKhK5 CGVGH/gi05hXuVwqLiCVNog5VV7w X-Google-Smtp-Source: ACJfBosLvCPdZ/6eJSCzdAuXuqfxgdLDkpYY+B4M8GLrvy+nxlF6irdmX8mOtXVktAOy06v1aWa8Cg== X-Received: by 10.80.212.158 with SMTP id s30mr27730059edi.286.1514215482416; Mon, 25 Dec 2017 07:24:42 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id h20sm25044290edh.69.2017.12.25.07.24.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Dec 2017 07:24:41 -0800 (PST) Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) To: Leo Liu , 24012@debbugs.gnu.org References: From: Dmitry Gutov Message-ID: Date: Mon, 25 Dec 2017 17:24:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 24012 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On 7/17/16 2:04 PM, Leo Liu wrote: > > 1. Use the attached file as an example, open it in emacs in ruby-mode > 2. Move point to end of buffer and eval (forward-comment (- (point))) > > The last step takes about 0.25 seconds on my MacBook 3 GHz Intel Core > i7. If you double the lines of comments, the time increase by 4 folds. FWIW, it looks fixed in the master branch now. Probably by 14b95587520959c5b54356547a0a69932a9bb480, so no idea what exactly was causing it. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 01:15:41 2019 Received: (at 24012) by debbugs.gnu.org; 29 Sep 2019 05:15:41 +0000 Received: from localhost ([127.0.0.1]:52008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iERYb-00030P-FC for submit@debbugs.gnu.org; Sun, 29 Sep 2019 01:15:41 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:33425) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iERYZ-00030C-LV for 24012@debbugs.gnu.org; Sun, 29 Sep 2019 01:15:40 -0400 Received: by mail-pf1-f194.google.com with SMTP id q10so3699278pfl.0 for <24012@debbugs.gnu.org>; Sat, 28 Sep 2019 22:15:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pUka9FLAiATRGU4UPdABlpf+O+Axx3Ybw1UBNxtZ2e8=; b=EFTRaoZNB17Zsks6g4SjCkZCF4mWNW6WZjQkDWfIHJkHHS/ggJ2iUmlvH+WzrNiCR/ +tpjqPio9/qn5DjQW84BCqM0D2P7jkXeKFKwvkFKJaR3fTcuykaJCBJZE9zTVzstcg9z lTxT993rRR3A9piP5Yi6kyZGBuEU/0CWOy1oIC+erlarvP3msLhQwq8QPAhNOL6MMF+X 8VMWX0xFWLiZTHfGGwkohBzOaUPmOGFKm/N+L1QxtAgwnybyRhSN7+S9JvlAS9NF6Jif 3rww3OyXhi7L+KTkydrTrQPB2Q6CpoL5aE5z8bDgOHzP3kHaaVKMYg0Y/HuhXA4jY/Hw LoXQ== X-Gm-Message-State: APjAAAViF2eUWnOfwW3qbSQmDJv3MWW3T35wRjoGp9MJAKOkBLjK+TFc gJXr1VqkCx8vZ+ODJa5pX9IM4IYPVpVIgegq/3U= X-Google-Smtp-Source: APXvYqzUA+MVxZ9lnYw/6bfDlwdw8QNwlbhSXEEpAqDRvGxj4WZ0vW7P+jysoeHtK7n8fDm9Fu5qD0B8qprVWVeXstc= X-Received: by 2002:a17:90a:cc08:: with SMTP id b8mr19615546pju.119.1569734133836; Sat, 28 Sep 2019 22:15:33 -0700 (PDT) MIME-Version: 1.0 From: Stefan Kangas Date: Sun, 29 Sep 2019 07:15:22 +0200 Message-ID: Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) To: Dmitry Gutov Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 24012 Cc: 24012@debbugs.gnu.org, Leo Liu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Dmitry Gutov writes: > On 7/17/16 2:04 PM, Leo Liu wrote: >> 1. Use the attached file as an example, open it in emacs in ruby-mode >> 2. Move point to end of buffer and eval (forward-comment (- (point))) >> The last step takes about 0.25 seconds on my MacBook 3 GHz Intel Core >> i7. If you double the lines of comments, the time increase by 4 folds. > > FWIW, it looks fixed in the master branch now. > > Probably by 14b95587520959c5b54356547a0a69932a9bb480, so no idea what exactly > was causing it. Indeed. I only see O(n) on current master -- that is, if I use the source code from the original report, and double the amount of lines by C-x h M-w C-y, the time to evaluate this expression in a buffer only doubles: (progn (end-of-buffer) (forward-comment (- (point)))) Leo, are you still seeing this issue? If I don't hear back within a couple of weeks, I'll just assume that this has been fixed and close this bug. Best regards, Stefan Kangas From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 07 22:59:24 2019 Received: (at 24012-done) by debbugs.gnu.org; 8 Nov 2019 03:59:24 +0000 Received: from localhost ([127.0.0.1]:44359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSvQh-000636-Sj for submit@debbugs.gnu.org; Thu, 07 Nov 2019 22:59:24 -0500 Received: from host.gofardesign.uk ([208.79.239.190]:40071) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSvQg-00062t-CU for 24012-done@debbugs.gnu.org; Thu, 07 Nov 2019 22:59:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=marxist.se; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qjUtv1XArZoNZRvdvXs7rmbeYY7rVO1l7KCnz3zly6c=; b=EAfzxazQB9AjHKzVeuV/mu9f5u qtzfYhfyVsBRZCMbEJVc1fZduJP/G5ldFcn8XZwxKa/s3eIWj/xTv84stAUcHGoWgf4+/KaLkPjfB VKVqTRO1N3U/AR4sRZcqgBrNOqLMeJV9uhB6jCfzT9LILmrnjC6vX2qanOIqpVpCx5TY=; Received: from h-70-69.a785.priv.bahnhof.se ([155.4.70.69]:52240 helo=localhost) by host.gofardesign.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iSvQa-0007oE-6n; Thu, 07 Nov 2019 21:59:16 -0600 From: Stefan Kangas To: Dmitry Gutov Subject: Re: bug#24012: 25.0.95; forward-comment backwards takes O(n^2) In-Reply-To: (Stefan Kangas's message of "Sun, 29 Sep 2019 07:15:22 +0200") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Fri, 08 Nov 2019 04:59:14 +0100 Message-ID: <87y2wruigd.fsf@marxist.se> MIME-Version: 1.0 Content-Type: text/plain X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.gofardesign.uk X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - marxist.se X-Get-Message-Sender-Via: host.gofardesign.uk: authenticated_id: stefan@marxist.se X-Authenticated-Sender: host.gofardesign.uk: stefan@marxist.se X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24012-done Cc: 24012-done@debbugs.gnu.org, Leo Liu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Kangas writes: > Dmitry Gutov writes: > >> On 7/17/16 2:04 PM, Leo Liu wrote: >>> 1. Use the attached file as an example, open it in emacs in ruby-mode >>> 2. Move point to end of buffer and eval (forward-comment (- (point))) >>> The last step takes about 0.25 seconds on my MacBook 3 GHz Intel Core >>> i7. If you double the lines of comments, the time increase by 4 folds. >> >> FWIW, it looks fixed in the master branch now. >> >> Probably by 14b95587520959c5b54356547a0a69932a9bb480, so no idea what exactly >> was causing it. > > Indeed. I only see O(n) on current master -- that is, if I use the > source code from the original report, and double the amount of lines > by C-x h M-w C-y, the time to evaluate this expression in a buffer > only doubles: > > (progn (end-of-buffer) (forward-comment (- (point)))) > > Leo, are you still seeing this issue? If I don't hear back within a > couple of weeks, I'll just assume that this has been fixed and close > this bug. More information was requested, but none was given within 5 weeks, so I'm closing this bug. If this is still an issue, please reopen the bug report. Best regards, Stefan Kangas From unknown Fri Jun 20 07:28:19 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 06 Dec 2019 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator