Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@andymass
Copy link

As pointed out by @chrisbra in #2712 (comment), BREAKCHECK_SKIP hasn't been changed in a very long time. Is it necessary to check so often for a break now? Especially since breaks are now checked in many places. Using the script in #2712 (comment) does show some benefit.

  • Also SYN_TIME_LIMIT is not defined in syntax.c since it's defined in screen.c
  • Possibly should update the value for windows and mac.

@codecov-io
Copy link

Codecov Report

Merging #4708 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #4708      +/-   ##
==========================================
- Coverage   81.38%   81.37%   -0.02%     
==========================================
  Files         114      114              
  Lines      145243   145244       +1     
==========================================
- Hits       118205   118187      -18     
- Misses      27038    27057      +19
Impacted Files Coverage Δ
src/misc1.c 80.64% <ø> (ø) ⬆️
src/syntax.c 82.62% <ø> (ø) ⬆️
src/ui.c 68.68% <0%> (-0.98%) ⬇️
src/ex_cmds.c 82.21% <0%> (-0.25%) ⬇️
src/os_unix.c 63.3% <0%> (-0.05%) ⬇️
src/terminal.c 81.25% <0%> (-0.04%) ⬇️
src/window.c 87.39% <0%> (+0.03%) ⬆️
src/term.c 79.16% <0%> (+0.05%) ⬆️
src/gui.c 63.75% <0%> (+0.05%) ⬆️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 61343f0...32eae1d. Read the comment docs.

@brammool
Copy link
Contributor

brammool commented Jul 21, 2019 via email

@brammool brammool closed this in b4fe0eb Jul 21, 2019
janlazo added a commit to janlazo/neovim that referenced this pull request Jul 21, 2019
…ssing text

Problem:    Too much overhead checking for CTRL-C while processing text.
Solution:   Increase BREAKCHECK_SKIP.  Remove the difference for when built
            with the GUI. (suggested by Andy Massimino, closes vim/vim#4708)
vim/vim@b4fe0eb
justinmk pushed a commit to neovim/neovim that referenced this pull request Jul 21, 2019
Problem:    Too much overhead checking for CTRL-C while processing text.
Solution:   Increase BREAKCHECK_SKIP.  Remove the difference for when built
            with the GUI. (suggested by Andy Massimino, closes vim/vim#4708)
vim/vim@b4fe0eb
timeyyy pushed a commit to timeyyy/neovim that referenced this pull request Aug 9, 2019
Problem:    Too much overhead checking for CTRL-C while processing text.
Solution:   Increase BREAKCHECK_SKIP.  Remove the difference for when built
            with the GUI. (suggested by Andy Massimino, closes vim/vim#4708)
vim/vim@b4fe0eb
manuelschiller pushed a commit to manuelschiller/vim that referenced this pull request Nov 10, 2019
…g text

Problem:    Too much overhead checking for CTRL-C while processing text.
Solution:   Increase BREAKCHECK_SKIP.  Remove the difference for when built
            with the GUI. (suggested by Andy Massimino, closes vim#4708)
@puremourning
Copy link
Contributor

should we make this change in os_mac.h too ? For some reason that hard-codes it to 32. I have been investigating significnt insert-mode performance issues that appear to suggest the line_breakcheck() in nfa_regmatch() to be the issue; repeatable on very wide terminal, but not on newly opened vim instance. I'm trying to work out a repro case and full explanation, but came across this and was curious if the macOS value is special for a specific reason ?

@brammool
Copy link
Contributor

brammool commented Mar 19, 2020 via email

@puremourning
Copy link
Contributor

I'll send a PR

Ben Jackson wrote:
should we make this change in os_mac.h too ? For some reason that hard-codes it to 32. I have been investigating significnt insert-mode performance issues that appear to suggest the line_breakcheck() in nfa_regmatch() to be the issue; repeatable on very wide terminal, but not on newly opened vim instance. I'm trying to work out a repro case and full explanation, but came across this and was curious if the macOS value is special for a specific reason ?
Good find. That must be a leftover from before Mac OS/X. Let's delete it, it should be the same as on other Unix systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants