Bug? B4A v.5.02 IDE on XP SP3 is very slow during typing on the keyboard.

sorex

Expert
Licensed User
the XP one is single core, this 7 is dual.

that scrollbar coloring feature is also redrawing at each keypress.
not sure what the use is of that as I can't seem to (double) click on it?

when you add all these features to the keypress event it seems that it lags on slower systems.

that's why I asked to make these optional to execute on compilation only/at keypress(/not at all).

maybe the lag is created somewhere else but if we can't try the above we will never know if the problem is there or not.

I am willing to volunteer as tester with unofficial test builds that could lead to a solid solution.
 

cyiwin

Active Member
Licensed User
My IDE is also slow. I think it started around the B4A 5.00 update. My computer has Windows 10 (Windows 8.1 was the same), i5-4670K @ 3.4 GHz and 16 GB RAM. Watching the Task Manager, B4A goes up to 25% CPU usage when typing. I usually keep typing away and the IDE updates every 2 seconds or so. If I'm in Debug (rapid) mode and adding code while my app is running the IDE can go up to 8 seconds before it updates my typing.
 

sorex

Expert
Licensed User
@cyiwin : that machine is far from slow so that shouldn't be the problem, does it help when you turn off the explicit auto completion?

Tools > IDE Options > Disable explicit autocompletion

for most people that solves most of the delay but then it's still slower than notepad or any other editor/ide.


@Erel : are there any plans to make that source scanning at each keypress optional? (and placed behind the alt-2 shortcut like before.)
 

Erel

Administrator
Staff member
Licensed User
are there any plans to make that source scanning at each keypress optional? (and placed behind the alt-2 shortcut like before.)
Almost all of the background operations are disabled when you turn off the explicit auto completion.

If you think that the background compilation slows down the IDE then you can change its interval by editing the ini file.

If your computer is not a single core computer then the background compilation shouldn't affect the performance.
 

sorex

Expert
Licensed User
ok, this wasn't mentioned before.

Is it this key?

BackgroundGuiThreadInterval2=50
 

cyiwin

Active Member
Licensed User
I wonder if other people get a high usage of CPU when holding down a key in the IDE (repeat the same character). If I hold down a key my CPU usage climbs to and holds at 60% within 10 seconds. Maybe note worthy, I downloaded MSI Afterburner and noticed my AMD R9 280X video card winds up to about 70% usage and slowly tapers off while holding down a key.

does it help when you turn off the explicit auto completion?
Disabling has no effect.

Does it happen with all projects?
I Tried running a smaller project and it is noticeably faster. Holding down a key climbs to 45% CPU. I suppose I have a total of 4000 lines of code in 4 modules, maybe that is the main issue.
 

sorex

Expert
Licensed User
compared to my home setup your box is ultra speedy and simular to my desktop at work and there I don't have the slow down. (I thought)

but after checking the keypressing I also see it peaks to 22-30% here but I don't have these press and wait pauses on this one.

doing the same thing in Notepad2 (which builds autocomplete lists of every words in documents) give 1-2%
 

MaFu

Well-Known Member
Licensed User
In my current project i have about 6000 lines of code (spreaded on 39 files, because i avoid huge files if possible).
The task manager shows me 3-7% cpu time (belongs to other background tasks, independent from B4A) and doesn't noticeable change on ide input (v5.20).
Same behaviour on both machines (Notebook i7/8GB and Desktop i7/24GB with Win7 x64).
 

sorex

Expert
Licensed User
Is that when keeping a key pressed or when it's just open, Manfred?

edit: ok, on both.
 

Erel

Administrator
Staff member
Licensed User
There are two relevant fields that you can modify:
BackgroundGuiThreadInterval2 and backgroundIndexerThreadInterval (note the case).

I suppose I have a total of 4000 lines of code in 4 modules, maybe that is the main issue.
4000 lines of code is not considered a large project.


The CPU usage is not very important. The latency (time between the key press and the character appearing) is the important factor.
 

sorex

Expert
Licensed User
I currently use

B4X:
BackgroundGuiThreadInterval2=30000
backgroundIndexerThreadInterval=30000
and keeping a key pressed still uses a lot of cpu but there are no delays.

if I use 5000 for the GUIThreadInterval then you see that it pauses a bit every 5 seconds and then starts printer letters again.
it's like it's choking on that pre-compile.

turning off the explicit autocomplete still makes it a bit faster tho.
 

sorex

Expert
Licensed User
it pauses a bit every 5 seconds and then starts printer letters again.
which means that the timer or "destination" timestamp doesn't get updated at keypresses.
It shouldn't kick in when you keep pressing chars but the "countdown" should start after the last key was pressed.
 

mc73

Well-Known Member
Licensed User
I, too, notice great latency while typing. Even if I turn off implicit auto completion, perfomance is just a bit better.
Running on windows 7 sp1, on 4gb ram and amd e-450.
I have the correct net framework. By the way, I can't seem to find any .ini file in the installation folder.
 

mc73

Well-Known Member
Licensed User
Using the intervals (30000) that sorex suggested above, the delay seems to be greatly decreased :)
 

Scantech

Well-Known Member
Licensed User
I can confirm using 30000 for both fields fixes the lagging issue. Now, I have no lag while typing . Before the fix, the characters shows after 2 to 5 seconds . The disadvantage with the changes is the intellisense does not kick in for 20 seconds . Im glad i bumped into this thread. Thanks
 

tchart

Well-Known Member
Licensed User
In an effort to be of help, I can also second the delay on my under powered (Mecer NetTop Atom 430N) running Win7 x64, .net 4.5.2. I also tried a fresh XP Virtual Machine on my 3rd gen i5 laptop, cannot test on host OS due to some .net issues, any-case same delay. Disabling 3d acceleration on the vm did remove most of the delay and the v5 IDE is very usable. Both run the v4.xx IDE very smoothly. Unfortunately re-opening my project on an earlier IDE produces a warning, and I don't want any additional issues. I will be formatting an older i5 (1st gen m520) Toshiba laptop and installing a fresh Win 7 sometime this week, will report back my findings here.
I have a similar issue with B4J on a Asus Eeebox (Intel Atom 4 core processor). The IDE is very sluggish with the auto complete. Usually I can manually type an line of code and the auto complete will take a good few seconds to complete. Disabling implicit auto complete doesnt help at all. I suspect the machine is just under powered as compiling to Debug takes around 40 seconds.
 
Top