Vim slows down because of parenthesis (etc.) matching #163
Comments
|
I also usually work with documents containing a lot of equations, and don't really experience these lags. It would be much easier to investigate this if you could define a minimal working example. That is, if you could give a simple tex file, something like this: \documentclass{minimal}
\begin{document}
... [content that leads to you problem]
\end{document}It would also help if you could further explain exactly how to reproduce the slowdown (keypresses and settings). Since I'm also working on a "fork" of LaTeX-Box, I would be very happy if you could check if this problem also happens there: vim-latex. If the problem does not happen with vim-latex, then I might fix it for LaTeX-Box by copying the modified pattern matching functions back to LaTeX-Box. |
|
Sorry for not sticking with bug reporting 101 and providing a working example. Below is the LaTeX file causing me problems (I include this in my main file using Also, I should note I use SPF13, but have tried to disable any of the included bundles I don't need. In particular the one that looks like it's related to matching backets etc. I'll try vim-latex next. Thanks! UPDATE: UPDATE 2: I have the same problem with your vim-latex. \section{Introduction}
\label{sec:introduction}
We consider the forward intensity approach of \citet{Duan:2012bh} where a company might exit the market because of default or for other reasons (i.e. a merger).
The authors model survival probabilities via a doubly stochastic Poisson process with an intensity $g_t(\tau)$.
However, this intensity is itself comprised of a default intensity $f_t(\tau)$ and an \emph{other exit} (i.e. due to a merger) intensity $h_t(\tau)$, and is therefore called \emph{combined exit} intensity.
Moreover, these intensities are \emph{forward} intensities assumed to be exponentially affine in a vector $X_t$ of state variables.
This approach alleviates the problem of having to compute the survival probability as an expectancy, which is necessary when employing spot intensities.
Overall, forward intensities for some stopping time $\tau$ in the \citeauthor{Duan:2012bh} framework can be expressed formally as
\begin{align}
\label{eq:def_intensities_duan}
f_t(\tau) &= \exp[\alpha_0(\tau) + \alpha_1(\tau) x_{t,1} + \alpha_2(\tau) x_{t,2} + \cdots + \alpha_K(\tau) x_{t,K}]\\
\label{eq:oth_intensities_duan}
h_t(\tau) &= \exp[\beta_0(\tau) + \beta_1(\tau) x_{t,1} + \beta_2(\tau) x_{t,2} + \cdots + \beta_K(\tau) x_{t,K}]\\
\label{eq:comb_intensities_duan}
g_t(\tau) &= f_t(\tau) + h_t(\tau),
\end{align}
where $\alpha(\tau) = (\alpha_0, \alpha_1, \cdots, \alpha_K)^\top$ and $\beta(\tau) = (\beta_0, \beta_1, \cdots, \beta_K)^\top$ are constant coefficient vectors for the specific stopping time $\tau$.
The resulting forward intensities' dynamics are driven by the covariate vector $X_t$.
Consider a prediction horizon $\tau$, measured in months $\Delta t = 1 / 12$.
Denote the time of default by $\tau_D$ and combined exit time by $\tau_C$.
Obviously, we have $\tau_C \leq \tau_D$.
In this setting the forward survival, default, and combined exit probabilities are given by
\begin{align}
\label{eq:fwd_prob_surv}
&P_t(\tau_C > t + \tau) = \exp\left[-\sum_{s = 0}^{\tau - 1} g_t(s) \, \Delta t\right]\\[0.5em]
\label{eq:fwd_prob_def}
&P_t(\tau_C; \tau_D = \tau_C \leq t + \tau) \notag\\
&=
\begin{cases}
1 - \exp\left[-f_t(0) \, \Delta t\right] & , \quad \text{if $\tau_C = t + 1$}\\
\!\begin{aligned}
& \exp\left[-\sum_{s = 0}^{\tau_C - t - 2} g_t(s) \, \Delta t\right] \times \\
& \left\{1 - \exp\left[-f_t(\tau_C - t - 1) \, \Delta t\right]\right\}
\end{aligned} & , \quad \text{if $t + 1 < \tau_C \leq t + \tau$}
\end{cases}
\end{align}
and
\begin{align}
\label{eq:fwd_prob_oth}
&P_t(\tau_C; \tau_D \neq \tau_C \land \tau_C \leq t + \tau) \nonumber\\
&= \begin{cases}
\exp\left[-f_t(0) \, \Delta t\right] - \exp\left[-g_t(0) \, \Delta t\right] & , \quad \text{if $\tau_C = t + 1$}\\
\!\begin{aligned}
& \exp\left[-\sum_{s = 0}^{\tau_C - t - 2} g_t(s) \, \Delta t\right] \times \\
& \{\exp\left[-f_t(\tau_C - t - 1) \, \Delta t\right]\\
&~- \exp\left[-g_t(\tau_C - t - 1) \, \Delta t\right] \}
\end{aligned} & , \quad \text{if $t + 1 < \tau_C \leq t + \tau$}
\end{cases}
\end{align}
respectively.
As is evident from the above equations, intensities are assumed to be piecewise constant for any given month.
\citeauthor{Duan:2012bh} assume the state vector $X_t$ to consist of firm specific variables and common factors.
For a sample of $N$ companies containing information regarding the companies' survival/default/other exit and the corresponding firm specific and common covariates of $X_t$ during a sample period of $T$ months, the authors construct the following pseudo-likelihood function for the parameter set comprised of $\alpha = \left\{\alpha(0), \alpha(1), \cdots, \alpha(\tau - 1)\right\}$ and $\beta = \left\{\beta(0), \beta(1), \cdots, \beta(\tau - 1)\right\}$, given a fixed $\tau$ for the maximum prediction horizon.
\begin{align}
\label{eq:likelihood_function_duan}
\mathcal{L}_t(\alpha, \beta; \tau_C, \tau_D, X) = \prod_{i = 1}^N \prod_{t = 0}^{T - 1} \mathcal{L}_{\tau, i, t}(\alpha, \beta)
\end{align}
where
\begin{align*}
\label{eq:likelihood_function_duan_part}
\mathcal{L}_{\tau, i, t}(\alpha, \beta) &= \mathbf{I}(t_{0,i} \leq t, \tau_{C,i} > t + \tau) \, P_t(\tau_{C, i} > t + \tau)\\
&+ \mathbf{I}(t_{0,i} \leq t, \tau_{D, i} = \tau_{C,i} \leq t + \tau) \, P_t(\tau_{C,i}; \tau_{D,i} = \tau_{C,i} \leq t + \tau)\\
&+ \mathbf{I}(t_{0,i} \leq t, \tau_{D, i} \neq \tau_{C,i}, \tau_{C,i} \leq t + \tau) \, P_t(\tau_{C,i}; \tau_{D,i} \neq \tau_{C,i} \land \tau_{C,i} \leq t + \tau)\\
&+ \mathbf{I}(t_{0,i} > t) + \mathbf{I}(\tau_{C,i} \leq t).
\end{align*}
The above probabilities are given by \eqref{eq:fwd_prob_surv} through \eqref{eq:fwd_prob_oth}, with the intensities depending on firm $i$'s state vector.
\citeauthor{Duan:2012bh} show that \eqref{eq:likelihood_function_duan} can be split into numerous pseudo-likelihoods; one per $\alpha(\tau)$, $\beta(\tau)$, and horizon
\begin{align}
\label{eq:likelihood_function_duan_split_alpha}
\mathcal{L}(\alpha(s)) &= \prod_{i = 1}^N \prod_{t = 0}^{T - s - 1} \mathcal{L}_{i,t}(\alpha(s)), & s = 0, 1, \cdots, \tau - 1\\
\label{eq:likelihood_function_duan_split_beta}
\mathcal{L}(\beta(s)) &= \prod_{i = 1}^N \prod_{t = 0}^{T - s - 1} \mathcal{L}_{i,t}(\beta(s)), & s = 0, 1, \cdots, \tau - 1,
\end{align}
where
\begin{align*}
\mathcal{L}_{i, t}(\alpha(s)) &= \mathbf{I}(t_{0,i} \leq t, \tau_{C,i} > t + s + 1) \, \exp\left[-f_{i,t}(s) \, \Delta t\right]\\
&+ \mathbf{I}(t_{0,i} \leq t, \tau_{D, i} = \tau_{C,i} = t + s + 1) \, \{1 - \exp[-f_{i,t}(s) \, \Delta t]\}\\
&+ \mathbf{i}(t_{0,i} \leq t, \tau_{d, i} \neq \tau_{c,i}, \tau_{c,i} = t + s + 1) \, \exp[-f_{i,t}(s) \, \delta t]\\
&+ \mathbf{i}(t_{0,i} > t) + \mathbf{i}(\tau_{c,i} < t + s + 1)\\[0.5em]
\mathcal{L}_{i, t}(\beta(s)) &= \mathbf{I}(t_{0,i} \leq t, \tau_{C,i} > t + s + 1) \, \exp\left\{-\left[g_{i,t}(s) - f_{i,t}(s)\right] \, \Delta t\right\}\\
&+ \mathbf{I}(t_{0,i} \leq t, \tau_{D, i} = \tau_{C,i} = t + s + 1) + \mathbf{I}(t_{0,i} \leq t, \tau_{D, i} \neq \tau_{C,i} = t + s + 1) \\
&\times \left\{1 - \exp\left[-(g_{i,t}(s) - f_{i,t}(s)) \, \Delta t\right]\right\}\\
&+ \mathbf{I}(t_{0,i} > t) + \mathbf{I}(\tau_{c,i} < t + s + 1).
\end{align*} |
|
I'm also experiencing this problem. Profiling vim shows that the The content which is encountering this problem, for me, is just a whole lot of text between begin and end document. I also used many fold markers ( |
|
Strange. I saved your test file and tested in full screen (I have a full screen resolution of 2560x1440): I don't get any [noticable] delays. I tried both using vertical and horisontal movements with Could you please test the same with a minimal vimrc file. You could use something like what I have pasted below, which is based on my own minimalvimrc file. You might prefer to remove or change some/all of the options I have used, but you need the set nocompatible
set rtp+=~/.vim/bundle/vim-latex " Or LaTeX-Box
filetype plugin indent on
syntax enable
if has("gui_running")
set lines=56
set guioptions=aeci
else
set t_Co=256
endif
set keywordprg=":help"
set autoindent
set backspace=indent,eol,start
set ttimeout
set expandtab
set ttimeoutlen=50
set laststatus=2 |
|
Yes, I would suspect that this problem can be due to FindMatchingPair, but I suspect that there might be a vim option that you have activated that makes the function run slower. It is difficult for me to investigate until I can reproduce. If you could also test if you experience the same problem with vim-latex, I would be happy. This is a fork that is designed to be slightly easier to debug, and so if the problem is there as well, then I can investigate it there and then apply the fix to LaTeX-Box afterwards. I can confirm that if I add surrounding parantheses to the entire content of the test file provided by @feju, then there is a slight delay (still talking ~100 ms) when I move past these parantheses. I also tested with both vim-latex and LaTeX-Box, and there seems to be no difference: Both plugins seems to be fast for the example provided, but have a slight delay when passing delimiters such as parantheses that contains a LOT of text (~100 lines). |
|
@lervag Did you do the movements by pressing the movement keys repeatedly or by pressing and holding them? I do the latter. I am running MacVim and Vim (both have the problem) installed from Homebrew on Mac OS X 10.9. Profile from my own vimrc: Profile from the vimrc you provided above: |
|
I've tried both repeated pressing and continuous pressing. Perhaps it works well with me because I'm on a fast computer? Could you explain how you do the profiling? Both how to start profiling (is it a vim functionality?) and exactly what you profile. Do you for instance only profile like 10 seconds of navigation? |
|
Just an example of what I mean when I say I am not affected. |
|
I'm also using vim-latex and I can't confirm any lags when keeping |
|
@nasenatmer I used a utility called ffcast, see here or here. To create the gif, I also needed to have byzanz-record installed. Then I used |
|
I'm having the same issue too with vim on os x (installed with homebrew). |
|
@lervag I am not seeing this problem with vim-latex. I switched from vim-latex to latex-box to avoid the keybindings, and that was when the performance problems emerged. I was using vim's built-in profiler ( |
|
@lervag I'm on a 2011 Mac Pro at work (that's where I did the testing). There should be enough performance... UPDATE: Just tested on my 2011 iMac (Core i7 3.4Ghz). Same issue. |
|
What version of vim are you all using? I am using vim 7.4.135, so perhaps I need to try an older version? If I understand correctly, the issue is confirmed by @darkfeline @feju and @Stelgard, where at least two of you use Mac. I can confirm that the cursor disappears when I hold a motion key, but I can still not reproduce the delays. That is, I can not confirm any substantial delays. Btw, @darkfeline, could you explain what you mean with "to avoid the keybindings"? In vim-latex you can turn off all keybindings through Update: Here is timing from me. Update 2: I tested with a minimal vimrc, and I found that the cursor no longer disappear. This indicates that the disappearance of the cursor is not because of LaTeX-Box (or vim-latex). Here is a timing from vim-latex as well: Update 3: Here's a new gif showing how it looks for me with a minimal vimrc file, fullscreen, with vim-latex. |
|
FWIW, heres my profile output though I don't quite understand it: Needless to say, I'm not using LaTeX-Box, but vim-latex. |
|
This is sort of strange, because based on the profiling results posted here, it seems that we get relatively similar results. That is, the result from @nasenatmer is very similar to that of @feju (and me). The result implies that it takes vim 0.58 seconds to run highlight_matching_pair 347 times (although much of the time is spent in the @feju Could you try to create a screencast (see my above comment for a tip on how to do this) where you could show me what is really happening? |
|
@lervag I meant expansions like for I'm using the default vim for Arch (here's all the version and compile option dump). I can confirm that the cursor lag and disappearing is caused by swapping out vim-latex for latex-box. Same config, without latex-box |
|
NOTE: Just as I was about to hit the comment button, I ran a few more tests to narrow down the cause. First, I overwrote the offending function by inserting in Original comment follows I've been trying to hunt down the cause of this slowdown myself. I get heavy cursor lag when editing large LaTeX files. As another commenter mentioned, this is not noticeable or at least less pronounced when the editor window isn't maximised. The latency is certainly there, though. If I hold a movement key long enough, then let go, there are occasions where the cursor will keep scrolling for a few (2-3) seconds before it stops. I have had a very hard time pinpointing the exact cause. This only happens when editing LaTeX files and it didn't seem to occur when I was using vim-latex. However, (this is where it gets interesting) if I remove LaTeX-Box and my personal LaTeX ftplugin file, the problem persists. I am forced to conclude that this is not a LaTeX-Box issue, but something else that is very specific to LaTeX. The fact that the cursor seems to "jump around" when scrolling points to something that requires drawing in other parts of the file. For example, I recall that having the Regardless, the fact that this issue persists when LaTeX-Box is removed, means that this issue shouldn't be here. I assume I am having the same issue as the other commenters --- I get similar results as the others mentioned when I run profiling, i.e., |
|
Hi, @achilleas-k. Thanks for your comments, they are interesting! I still do not see any good way to fix this globally from within LaTeX-Box, but I think your comment might help some people to resolve the issue locally. |
|
I ran into the same problem but with using vimtex with neovim. I profiled in neovim with the 2 different setups. And here is the profiling output with I paste the summary here for clarity: with |
|
Hi, |
|
IMHO, LaTeX-Box is deprecated. I recommend you try vimtex. |
|
@lervag Thank you for reply. |
|
If you don't have clientserver, then you can use an option to disable the feature that requires it. For instance, this: let g:vimtex_compiler_latexmk = {'callback' : 0} |
|
@lervag Thank you so much. |
|
No problem. I'm sorry, but it is very difficult for me to say whether it is natural or not with the delay based on such a vague description. If you feel it is a problem, don't hesitate to open a new issue on the vimtex repo. If so, please adhere to the issue template and provide a reproducible and minimal example. |
|
I got same problem and my vim profiling output was the same as @felixjung . So it is probably cause by sync settings. When I removed |
|
I had the same problem as everyone, and here is what worked for me. I tried migrating to vimtex, but that brought along a bunch of bugs: I could not for example hit enter in the jump list to go to the errors I was used to seeing in latex-box. Perhaps these can all be fixed, but I chose to fix the small annoyance in latex-box by disabling the feature and moving on with my life. After inspecting the code in LaTeX-Box/ftplugin/latex-box/motion.vim you find a function that says that you can disable the FindMatchingParen() functionality by setting the variable: The variable |
|
Same problem over here: |
|
Just mentioning: I don't think anyone is maintaining this repo. You should consider trying vimtex. |
Hi,
I usually edit latex code with lots of equation environments and therefore many open and close patterns. LaTeX-Box tries to detect and highlight these patterns, which is a really helpful feature. From the help I know that the patterns are set using the g:LatexBox_open_pats and g:LatexBox_close_pats variables.
With the default setting my vim slows down a lot when moving between lines or within a line in inline math or an equation environment using the
h,j,k,lkeys. When holdinghorlfor a longer time this may even cause Vim to become unresponsive for a number of seconds.Setting the above variables to empty lists (i.e. '[]') fixes any performance issues, but obviously also disables the matching feature.
Is there a way to improve the performance? Maybe only check for matching opening and closing patterns once the cursor stood still for half a second or so?
Thanks!
The text was updated successfully, but these errors were encountered: