Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance hit in completing numbered list #96

Open
ElectrifyPro opened this issue May 1, 2021 · 9 comments
Open

Performance hit in completing numbered list #96

ElectrifyPro opened this issue May 1, 2021 · 9 comments

Comments

@ElectrifyPro
Copy link

I have a .txt file that has a section in the middle with this format (the list is 30-ish entries long):

...
10. Title 10
• example
• example
• example
• example
11. Title 11
• example
• example
• example
• example
12. Title 12
...

When I place my cursor on the line 12. Title 12 and press o, there is a ~1 second pause before the next 13. line is added. However, when I remove all the lines with • example and repeat the two above steps, there is no pause. I found that the more • example lines that I add in between a numbered entry, the pause gets worse and worse.

@harshad1
Copy link
Collaborator

harshad1 commented Jun 8, 2021

Could you share a sample file here?

@ElectrifyPro
Copy link
Author

Here's the repository that has the example: https://github.com/ElectrifyPro/cautious-spoon

There's two files, culprit.txt contains the problem that I showed above. If you put your cursor on any numbered line and press o, there is a delay before the next line is added.

normal.txt is culprit.txt, but with all the items in between each numbered entry removed. There aren't any problems with that file.

@harshad1
Copy link
Collaborator

harshad1 commented Jun 9, 2021

Thanks.

Could you check if let g:bullets_renumber_on_change = 0 improves the performance?

@ElectrifyPro
Copy link
Author

Yes, setting that option to 0 does indeed fix the delay.

@harshad1
Copy link
Collaborator

The issue here is that parse_bullet

  1. Does a lot of work
  2. Is called 2x for every element of the list

Having to parse each bullet 2x when walking the list is pretty normal. Improving the performance of parse bullet is what will help here.

@harshad1
Copy link
Collaborator

I have a PR to help address this here: #107

Would you be able to check if it helps your case? You'll likely have to add my clone as an origin and checkout my branch.

@ElectrifyPro
Copy link
Author

Unfortunately there still is a delay when I tried your fix on culprit.txt. Just to make sure I did it correctly, this is what I put in vimrc:

"Plug 'dkarter/bullets.vim'
Plug 'harshad1/bullets.vim', {'branch': 'performance_improvements'}

Also is it necessary for parse_bullet to be called 2x for every list item? Would it not work properly if it was only called once?

@harshad1
Copy link
Collaborator

Unfortunately there still is a delay

Any improvement though?

Also is it necessary for parse_bullet to be called 2x for every list item?

Technically, no. But in general you need to walk to the top of the list and then back to the bottom. I am looking at strategies to address this. Reducing the calls to parse_bullet would likely yield the greatest performance improvement

@ElectrifyPro
Copy link
Author

Unfortunately there still is a delay

Any improvement though?

No, there isn't any noticeable improvement as far as I can tell

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

No branches or pull requests

2 participants