Dear Odd and Ondra,

I did manage to find an earlier (2011) discussion (propmpted by Ondra) of a
very similar problem, with very similar functions being implicated
(rendering error markup). The specific problem was that a
re-search-backward call was being made with a nil second argument, forcing
it search the buffer all the way back. The fix at the time was to
hard-limit the search. In the ~2013 version of matlab.el that I have, the
search was limited to 8192 chars back. As a temporary  measure I've limited
it even further to ~800 chars, to see if it makes a difference. Will let
you know if it does, and if not, will try your solution Odd.

Thanks for your help and suggestions,

Sina


2014-03-06 9:22 GMT+00:00 Odd Andersen <odd.ander...@gmail.com>:

> Hi,
>
> I used to have the same problem, and found it frustrating that there
> seemed to be no discussion of this issue anywhere.  Finally, I was able to
> fix it myself.
>
> Here's what I did:
>
>    1.  I ran matlab-shell with my usual workflow until it started
>    becoming unresponsive.
>    2. I started the emacs profiler: (profiler-start 'cpu)
>    3. I hit enter a couple of times in the matlab-shell, waiting a few
>    seconds for the shell to respond.
>    4. I asked the profiler for a report (profiler-report)
>    5. From the report, it turned out that most of the runtime was spent
>    in a single function whose task is to render errors as anchors (which I
>    don't particularly care about).
>    6. This function is hooked into matlab-shell-mode when it start.  As a
>    workaround, I added another hook that removes this hook, by including the
>    following lines in my .emacs file:
>
>
>
> *(add-hook 'matlab-shell-mode-hook       (lambda () (remove-hook
> 'comint-output-filter-functions
> 'matlab-shell-render-errors-as-anchor t)))*
>
>  I have not had any issues with unresponsive matlab shell after I did
> this.  If your problem has the same cause as mine, this hopefully works for
> you too.  (Make sure to get the quotation marks in the above command right,
> as well as the final 't' on the last line...).
>
> Odd A.
>
>
>
> ------------------------------
> -------- Original Message --------
>   Subject: [Matlab-emacs-discuss] matlab-emacs slows down  Date: Wed, 5
> Mar 2014 18:51:01 +0000  From: Sina Tootoonian 
> <sina.tootoon...@gmail.com><https://webmail.sintef.no/owa/redir.aspx?C=7u2jHFM45kiDABWqV6fI02wyMtT6B9EIn6FZnc1WYUOX0Gl19XWr3b0pnDSeinQ8CMAbLPXIWeM.&URL=mailto%3asina.tootoonian%40gmail.com>
>   To:
> matlab-emacs-discuss@lists.sourceforge.net<https://webmail.sintef.no/owa/redir.aspx?C=7u2jHFM45kiDABWqV6fI02wyMtT6B9EIn6FZnc1WYUOX0Gl19XWr3b0pnDSeinQ8CMAbLPXIWeM.&URL=mailto%3amatlab-emacs-discuss%40lists.sourceforge.net>
>
> Hi folks,
>
> First, great job on the update to matlab-mode, a big improvement on
> the version I was using before (~2003). One problem I've noticed is
> that the CLI slows down considerably after a while, perhaps due to the
> buffer getting large ( O(10k) lines). I usually end up restarting
> matlab-shell to get the responsiveness back. Is there a better
> workaround for this?
>
> Thanks!
>
> Sina
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to 
> Perforce.http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>  
> <https://webmail.sintef.no/owa/redir.aspx?C=7u2jHFM45kiDABWqV6fI02wyMtT6B9EIn6FZnc1WYUOX0Gl19XWr3b0pnDSeinQ8CMAbLPXIWeM.&URL=http%3a%2f%2fpubads.g.doubleclick.net%2fgampad%2fclk%3fid%3d122218951%26iu%3d%2f4140%2fostg.clktrk>
> _______________________________________________
> Matlab-emacs-discuss mailing listmatlab-emacs-disc...@lists.sourceforge.net 
> <https://webmail.sintef.no/owa/redir.aspx?C=7u2jHFM45kiDABWqV6fI02wyMtT6B9EIn6FZnc1WYUOX0Gl19XWr3b0pnDSeinQ8CMAbLPXIWeM.&URL=mailto%3aMatlab-emacs-discuss%40lists.sourceforge.net>https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>  
> <https://webmail.sintef.no/owa/redir.aspx?C=7u2jHFM45kiDABWqV6fI02wyMtT6B9EIn6FZnc1WYUOX0Gl19XWr3b0pnDSeinQ8CMAbLPXIWeM.&URL=https%3a%2f%2flists.sourceforge.net%2flists%2flistinfo%2fmatlab-emacs-discuss>
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Matlab-emacs-discuss mailing list
> Matlab-emacs-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>
>
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Matlab-emacs-discuss mailing list
Matlab-emacs-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Reply via email to