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

Autocomplete works, but speed is so slow( #66

Open
Partysun opened this issue Dec 14, 2014 · 11 comments
Open

Autocomplete works, but speed is so slow( #66

Partysun opened this issue Dec 14, 2014 · 11 comments

Comments

@Partysun
Copy link

I have more than 0.5-1 sec for some classes/functions lag after write dot symbol.
Thank you,

@jdonaldson
Copy link
Owner

Are you using OpenFL? What is the size of your project you are working with? Are you using NeoComplCache, or YouCompleteMe?

@Partysun
Copy link
Author

OpenFL, actually not big source, YouCompleteMe.

On Mon, Dec 15, 2014 at 2:51 AM, Justin Donaldson
notifications@github.com wrote:

Are you using OpenFL? What is the size of your project you are working with? Are you using NeoComplCache, or YouCompleteMe?

Reply to this email directly or view it on GitHub:
#66 (comment)

@jdonaldson
Copy link
Owner

Are build times slow as well?

@Partysun
Copy link
Author

Nop build time is not bad. Flash time is very fast 1-5 sec. And ios 20-120 sec, if it is not first compile.

понедельник, 15 дек. 2014 г. в 3:10 пользователь Justin Donaldson notifications@github.com написал:

Are build times slow as well?


Reply to this email directly or view it on GitHub:
#66 (comment)

@jdonaldson
Copy link
Owner

the autocompletion uses the compiler to determine completions. So, your completion times are sometimes very similar to your build times.

Try to update your vaxe bundle one more time, and then issue the command:

:VaxeToggleLogging

and then try any completion. Next, open your debugging messages with

:mess

You should see a build command similar to:

cd "/Users/jjd/Projects/flux"; haxe  
-main ApplicationMain 
-cp /usr/lib/haxe/lib/openfl/2,0,1/ 
-D openfl=2.0.1 
-cp /usr/lib/haxe/lib/promhx/1,0,8/src/main/ 
-D promhx= 
-cp Source 
-cp ./External/xml176/src/
main/haxe 
-cp /usr/lib/haxe/lib/openfl/2,0,1/backends/native 
-D tools=1.5.7 
-D lime_native 
-D no
-compilation 
-D native 
-D openfl
-native 
-D display 
-D mac 
-D desktop 
--no
-output  
--remap flash:openfl 
-cp E
xport/mac64/neko/haxe 
-neko Export/mac64/neko/obj/ApplicationMain.n 
--macro keep\(\"Main\"\) 
-D absolute_path 
-D no
-copt 
--display /Users/jjd/Projects/flux/Source/Flux.hx@2149  2>&1

paste that here, and let's see if there's anything in there that is hurting performance

@jdonaldson
Copy link
Owner

i'm going to close that out, reopen if you see any more issues.

@slouffka
Copy link

Same problem here. It's insanely slow. It's annoying and getting me mad because I use Vim for its SPEED. Can't work like that :(

Btw YCM for C++ works lightning fast. Why it's so slow for Haxe? All Haxe libs are compiled to C++ every time I type anything? Sorry to say that but it makes Vaxe unusable though you've did really great job with it in total.

It there any way to make the completion fast? What part of my code gets recompiled?

@jdonaldson
Copy link
Owner

Sorry to hear. It shouldn't slow things down "every time you type something". Only when you

  1. invoke the autocompletion method directly
  2. use an autompletion package like YCM that invokes the autocompletion method after a trigger key (period or paren).

Same request goes for the previous person... give me some information about the hxml generated by vaxe, as well as give me some information on which version of openfl/haxe you're using. A reproducible example would be great as well... does this happen on one of the "demo" projects?

@jdonaldson jdonaldson reopened this Jan 27, 2017
@slouffka
Copy link

slouffka commented Jan 27, 2017

Thanks for the response.

Yeah. You're right about triggering. My fault to say that way. But I type fast so that feels just like every time I type :) I mean now it's times faster to type without autocomplete what I am exactly doing to write code. Sometimes it so slow that my code got glithches which makes editing a pain. I'll make a screenshot when it happens. Occured only with Haxe/Vaxe. Not with any other plugins or languages like C++ or JavaScript.

Yes, it happens with any code. Like Flixel TiledEditor demo for example.

Just tried openfl 3.6.1 and 4.3.1. Used sample DisplayingABitmap. Both versions lags like a 1-2 seconds before showing the list on typing period or invoking with ctrl+space. Not only first time but any time I invoke it with any method.

I noticed that lag on 3 different machines. Core 2 Duo desktop, i3 notebook, i7 desktop. Only i7 works somewhat like okay but even that I can't call fast.

We could look into VS Code Haxe autocompletion implementation because it works fast and feels very smooth. Looks like they use some other way to make it. https://github.com/vshaxe/vshaxe.

@jdonaldson
Copy link
Owner

Thanks, I'll check it out. I know the folks working with vscode, and I'll see how they're doing it.

@bloognoo
Copy link

I know this has been resting a while, and I don't know how much this helps as we're years down the line, but I've had a recent performance drop following updating my plugins that I rectified by knockout out Syntastic and YouCompleteMe.

Syntastic lags buffer swapping ; air/powerline updates maybe 3 seconds before the buffer updates
YouCompleteMe lags when hitting periods, brackets, etc and stalls 3 seconds, including visual corruption to the buffer until ycm returns and the buffer refreshes.

I'm going to have a dig and see if it's the haxe language server that is still bogging down the response, and maybe what changed. This may have been round about the 8.2 of vim which added async capabilities, sothat's another moving part to check :)

If anyone's ahead of me on this, please let me know.

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

4 participants