-
Notifications
You must be signed in to change notification settings - Fork 110
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
Cause long php files to be slow. #109
Comments
Thank you for tracking this one down. I've tried to run the tests without them and things seem to pass. The only thing we used those to skip comments when we are looking for beginnings and ends of functions/classes but the normal comment area patterns would cover those, so I'd say it should be safe to merge. Would you mind giving this issue-109 branch a try for a few days to see if i'm missing something? |
I checked out your branch with the items commented out, but no luck. I did see some speed improvement, but not the amount I was looking for. On a hunt to find out where else that regex is being called from |
So I found a workaround to my issue.
Thank you for trying to resolve the slow down. |
Hmm, wait- now I'm confused 😊 The syntax file in this plugin is only used for hidden buffers the plugin uses to parse source code (mainly to find a function's opening / closing
The file you are actually editing shouldn't be affected by the syntax file in the repo, but the usual php syntax file you get with vim (or a third party) - correct me if I'm wrong here. |
Hmmm, interesting to know. I wasn't aware. I'll do a deeper test (fresh
install of vim, clean vimrc, and only your package and Plugged) to see what
i can find, perhaps the issue is linked to something else.
I am notorious for having numerous buffers, splits, and tabs open. However
the issue does happen with a new instance and only one file open. I did
find that it only slows down when you are in a class with over a 1000 lines
and you are editing with at least 800 lines left of the class.
I'm on vim7. The numbers still stand, removing the syntax file gave an
improvement of 30% in this scenario. Perhaps with a fresh install, i can
better describe the scenario.
On Apr 14, 2018 4:58 AM, "complex857" <[email protected]> wrote:
Hmm, wait- now I'm confused 😊
The syntax file in this plugin is only used for hidden buffers the plugin
uses to parse source code (mainly to find a function's opening / closing { }
pairs and to see if things are in comments and/or strings) and in general
should only be a slow-down on typing when you either:
1. Start the completion (triggering with ctrl+xo or so)
2. When you have had some base of completion and you are deleting
backwards of that (re-triggers the whole search with a new shorter base).
The file you are actually editing shouldn't be affected by the syntax file
in the repo, but the usual php syntax file you get with vim (or a third
party) - correct me if I'm wrong here.
The file type the plugin has a syntax for is named phpcompletetempbuffer in
hopes it won't collide with anything. If you check the value
b:current_syntax and you see anything else then it shouldn't be related.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#109 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAawIVHt0hmuQRw-aW7qJq99xsj3viBQks5tobohgaJpZM4TSTXN>
.
|
Forcing the hereDoc and nowDoc to syntax highlight if people don't want to use them is a little rough, considering it causes slowdowns on larger files.
After running syntime on a thousand line php file; the slow down, for these three ( javascript, sql, html ) to run, was around .24 seconds each per render. That is a whole second between key strokes.
https://github.com/shawncplus/phpcomplete.vim/blob/master/syntax/phpcompletetempbuffer.vim#L28-L39
The text was updated successfully, but these errors were encountered: