B4J Question Very large app -> slowdowns in code editor

[MegatenFreak]

Hello.
The app I'm working on has been under development for two years, and it's currently massive, with more than 100,000 lines of code distributed in 150+ code modules.
For some time now I've been experiencing annoying slowdowns when coding in B4J and long lags in the smart error detection and the intellisense thing. I suppose it's due to the great size of the code. But I was wondering if there's anything I can do to reduce the lags and slowdowns.
Any suggestions are appreciated. Thanks.

 

[agraham]

Compile your most stable code as libraries.

 

[Erel]

What is the memory usage (check with task manager)?

The first thing that I would have done is to take 100 of these modules and make them a b4xlib. It is very simple to do and it will help.

 

[MegatenFreak]

What is the memory usage (check with task manager)?

The first thing that I would have done is to take 100 of these modules and make them a b4xlib. It is very simple to do and it will help.

Memory usage begins at around 700 MB and gradually rises to nearly 2GB. I close and reopen B4J once in a while to remedy that. I think it's a memory leak, but I've never managed to find and cure it.
The library idea is exactly what I was looking for! a way to lighten the load. That would be great! and if I need to change part of it I can always edit the library.
I've never created a b4xlib. Could you point me in the right direction? Thanks a lot.

 

[Sandman]

Could you point me in the right direction? Thanks a lot.

Sure, that's the direction:

Searching for b4xlib gave this post as #4 in the results:

[new feature] b4xlib - a new type of library

As B4X matures, more and more reusable components are written in B4X directly. In most cases it is simpler to implement the logic in B4X directly and the code can be cross platform. Especially with the relatively new XUI library. Standard libraries will never be cross platform as they are...

www.b4x.com

 

[MegatenFreak]

Cool! Thanks! what a lovely arrow!!!
I have my laziness to blame!

 

[klaus]

You may have a look at chapter Generate a B4X Library *.b4xlib in the B4X Custom Views booklet.

 

[Erel]

The IDE will soon be a 64 bit process. This will help with the memory usage as it will allow the IDE to consume more than 2gb or RAM.
It will help in this case.

 

[MegatenFreak]

That will be incredible

 

[amykonio]

The IDE will soon be a 64 bit process. This will help with the memory usage as it will allow the IDE to consume more than 2gb or RAM.
It will help in this case.

Hi Erel.
The x86 ide will stop, or both x86 & x64 will be available?
Andreas.

 

[Erel]

New versions will be released with 64 bit version.
The latest 32 bit version will also be available for download.

 

[agraham]

The latest 32 bit version will also be available for download.

I'm afraid that is a bit ambiguous - it could mean that you will just keep the present current versions available as 32 bit or do you intend that both 32 and 64 bit versions will be released for all future versions?

 

[amykonio]

I'm afraid that is a bit ambiguous - it could mean that you will just keep the present current versions available as 32 bit or do you intend that both 32 and 64 bit versions will be released for all future versions?

Well, my understanding is that new versions will be in x64. There will be a link to the last x86 build. Anyway, I believe that in long term we will have to use the x64 ide. Most computers today are running x64 windows.

 

[Erel]

Well, my understanding is that new versions will be in x64. There will be a link to the last x86 build. Anyway, I believe that in long term we will have to use the x64 ide. Most computers today are running x64 windows.

Exactly.

 

[MegatenFreak]

The library idea is exactly what I was looking for! a way to lighten the load. That would be great! and if I need to change part of it I can always edit the library.

I gave the idea a try. Unfortunately, I couldn't use a normal (compiled) library, since my modules are very interdependent and 90% of them have their own layouts. I tried b4xlib. It does work, but has no effect on memory consumption and speed, which is no surprise as the library code is still present and active.
I guess I'll await the x64 IDE version. I hope that would improve the situation.

 

[agraham]

Sorry

There will be a link to the last x86 build.

Exactly.

Sorry about being pedantic but this is still ambiguous in colloquial British English. It could mean that either the x86 build will always be (say) B4A v11 or it could mean that the x86 version is of the latest x64 version.

The 'last one' can have the double meaning of being the 'final one' or the 'latest one'. You can't tell which is the intended meaning without further qualification.

 

[MegatenFreak]

According to the explanations given, I believe "the last x86 build" means "the final one".
So, after a set version, we will no longer have 32-bit versions. For example, if, say, B4J 12.1 is the breaking point, then the x64 version will keep going higher, but 12.1 will always remain the last 32-bit version to be released.

 

[agraham]

According to the explanations given, I believe "the last x86 build" means "the final one".

I can't see Erel clarifying that anywhere. You may 'believe' it but as I have pointed out up to now all the statements are ambiguous.

 

[MegatenFreak]

I can't see Erel clarifying that anywhere. You may 'believe' it but as I have pointed out up to now all the statements are ambiguous.

I don't mean to drag the conversation on, but just to clarify, the "I believe" part was just a habit I picked up from essay writing. What amykonio stated clearly signifies that there won't be x86 updates after a certain version, and Erel responded with "Exactly", which, well, is a perfect indication that he has verified the previous statement.

 

[agraham]

What amykonio stated clearly signifies that there won't be x86 updates after a certain version

Sorry but it doesn't. The Chambers dictionary definition of 'last' is

Last
1.Latest
2.Coming or remaining after all the others
3.Final
4.Immediately before the present
5.Utmost
6.Ending a series
7.Most unlikely, least to be preferred

Note the ambiguity of meaning of (1) and (3) above. None of the statements regarding the x86 version clarify the intended meaning.