Autocomplete works, but speed is so slow(
Opened this issue · 11 comments
I have more than 0.5-1 sec for some classes/functions lag after write dot symbol.
Thank you,
Are you using OpenFL? What is the size of your project you are working with? Are you using NeoComplCache, or YouCompleteMe?
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)
Are build times slow as well?
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)
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
i'm going to close that out, reopen if you see any more issues.
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?
Sorry to hear. It shouldn't slow things down "every time you type something". Only when you
- invoke the autocompletion method directly
- 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?
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.
Thanks, I'll check it out. I know the folks working with vscode, and I'll see how they're doing it.
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.