Android Question Slow Compile

[iCAB]

Hi There

I am working on a relatively large project.
At a certain point (when the project was almost 2/3 of the Current size ), I started facing issues with the compiler being very slow and my PC shutting down (sudden death) during compile.

By changing the ini file to:
MaxRamForDex=1536

The issue was resolved.

Now that the project grew more in size, I Started facing the same issue again (PC Shutdown and very slow compile). It is important to mention that before the shutdown, the PC fan goes crazy during compile.

Some project Info:
1. The project use google play service ( google maps and gcm )
2. over 30K lines
4. apk size is 6.8MB

One thing I have noticed:
Moving code from inside the activities to create classes ( the exact same code more or less), increased the compile time by a lot


PC & Compile Info:
Windows 7, AMD 3100MHZ 4 cores, 8GBRAM)


Compiler Window info in release mode
B4A version: 5.50
Parsing code. (1.06s)
Compiling code. (1.76s)
Compiling layouts code. (0.01s)
Generating R file. (0.42s)
Compiling generated Java code. (11.55s)
Convert byte code - optimized dex. (31.36s)
Packaging files. (2.78s)
Copying libraries resources (0.10s)
Found 3 resource files.
Signing package file (private key) (4.07s)
ZipAlign file. (0.12s)
Installing file to device.


In Debug Mode
B4A version: 5.50
Parsing code. (1.94s)
Compiling code. (4.79s)
Compiling layouts code. (0.01s)
Generating R file. (0.79s)
Compiling generated Java code. (9.57s)
Convert byte code - optimized dex. (45.98s)
Packaging files. (4.54s)
Copying libraries resources (0.13s)
Found 3 resource files.
Signing package file (private key) (3.39s)
ZipAlign file. (0.07s)
Installing file to device.


After following the instructions in this thread
https://www.b4x.com/android/forum/t...-google-play-apis-into-b4a-application.61537/

In Debug Mode
B4A version: 5.50
Parsing code. (1.35s)
Compiling code. (2.68s)
Compiling layouts code. (0.01s)
Generating R file. (0.43s)
Compiling generated Java code. (12.31s)
Convert byte code - optimized dex. (44.45s)
Packaging files. (3.10s)
Copying libraries resources (0.11s)
Found 3 resource files.
Signing package file (private key) (2.06s)
ZipAlign file. (0.08s)
Installing file to device. (31.57s)
Device serial: ZX1D529NPB
Completed successfully.


Also I can only use the debugger in legacy mode
I tried Clean Project but I never tried clean unused files, as I don't think there are many and I am also not sure how would this effect the compilation time.

any help is greatly appreciated


Thanks in advance

 

[JakeBullet70]

There are a few of us with large projects that have issues with the rapid debugger. Erel is aware of it and looking for a solution. One thing I have found is uninstalling your test app occasionally and installing fresh. But this does not always work.

A few questions:
What generation of AMD processor do you have?
How much free RAM do you have when you compile?
What kind of hard drive? SSD or HD?

 

[iCAB]

Hi Jake
Thanks for the quick reply.Here is some more info:

1. CPU AMD Fx(tm)-8120
2. 7.72GB usable .. Task Manager shows Physical Memory 54%
3. not an SSD just a regular drive.

 

[JakeBullet70]

That AMD 8120 is an 8 core proc. Anyway plenty fast.
You have free RAM so that limits swapping to the page file.
I would think your bottle neck would be your hard drive.

As an example. My laptop is a 2nd gen Core I3, 8gig of RAM and a 240gig Samsung SSD.
My sons laptop is a 4th gen core I7, 8gig of RAM and a regular hard drive.

But... I compile the same b4a project faster. An SSD makes a HUGE difference.

As far as your PC shutting down I would think think you might be over heating. You can get CPUID
http://www.cpuid.com/softwares/cpu-z.html They have a stress test. Try that and see if your computer shuts down.

 

[JakeBullet70]

My impression is that the problem lies with Windows and not so much B4A. Windows simply cannot handle the amount of tasks involved in debugging such a large project

I do not think that is it. At my main job we have over 100,000 lines in VB.NET and Windows has no issues with it.

 

[JakeBullet70]

Personally I have always been impressed how well VB6 works

I miss VB6... LOL.

Rick, have you made any library's out of some of your stable code in your app to reduce the size of source code. I think I am going to try that. Anyway if will make the compile go faster.

 

[Erel]

If you are using B4A v5.80 then you can use the new #ExcludedClasses attribute to exclude classes from Google Play Services (and any other library): https://www.b4x.com/android/forum/threads/new-feature-three-birds-with-one-stone.63127/#content

It is simpler than modifying the zip files.
You should also increase the value of MaxRamForDex. Start with 2048.

Cleaning the project (ctrl + P) before compiling with the rapid debugger will in most cases solve debugging issues.

If anyone has a project that causes the rapid debugger to fail then if possible please send it to me ([email protected]). It will help with improving the debugger.

 

[JakeBullet70]

Condensing the number of global variables

Is there a limit to the numbers of const and/or global vars?

 

[iCAB]

If you are using B4A v5.80 then you can use the new #ExcludedClasses attribute to exclude classes from Google Play Services (and any other library): https://www.b4x.com/android/forum/threads/new-feature-three-birds-with-one-stone.63127/#content

I downloaded b4A 5.80 and followed the steps recommended in Post#10

Below are the new results

B4A version: 5.80
Parsing code. (2.06s)
Compiling code. (5.20s)
Compiling layouts code. (0.00s)
Generating R file. (0.86s)
Compiling generated Java code. (10.79s)
Convert byte code - optimized dex. (16.72s)
Packaging files. (2.57s)
Copying libraries resources (0.23s)
Found 3 resource files.
Signing package file (private key) (3.73s)
ZipAlign file. (0.13s)
Installing file to device.

Huge difference. I wish I posted this long time ago.

One thing for sure. An amazing community with the best support anyone can ask for.

Thanks to all of you

 

[Widget]

I am working on a relatively large project.
At a certain point (when the project was almost 2/3 of the Current size ), I started facing issues with the compiler being very slow and my PC shutting down (sudden death) during compile.
...
Now that the project grew more in size, I Started facing the same issue again (PC Shutdown and very slow compile). It is important to mention that before the shutdown, the PC fan goes crazy during compile.

It sound to me like you could have bulging capacitors on your power supply or motherboard because your computer is shutting down unexpectedly. When the CPU is heavily taxed for more than a few seconds, it will draw more power and faulty capacitors will cause the computer to become unstable. I had a computer that would blue screen or reboot when playing videos after several minutes but the rest of the time the computer ran fine. So it is my thinking that the long B4A compiles are causing a lot of work from the CPU which increases a prolonged strain on the faulty caps that results in unstable voltages on your motherboard.

To examine the caps shut the computer down and unplug the power cord from the computer and press the power switch to discharge any remaining voltage. Put the computer on a table where you have good lighting and open it up. Look for electrolytic capacitors (looks like a small soda can) that have white goo on the top or are bulging at the sides. Use a magnifying glass and a flashlight. Take a close up picture of the suspect caps if you are unsure and post it here.

If the bad caps are on the motherboard, it is very difficult to replace them because of the extremely fine traces on the board. Caps on the power supply can be easily replaced or if you're not handy with a soldering iron just replace the power supply if that is where the bad caps are located. If the bad caps are on the motherboard you are better off replacing the motherboard.

Hope this helps.

 

[JakeBullet70]

If anyone has a project that causes the rapid debugger to fail then if possible please send it to me ([email protected]). It will help with improving the debugger.

Erel.
I sent you a link to download my project. Thanks.

 

[iCAB]

It sound to me like you could have bulging capacitors on your power supply or motherboard because your computer is shutting down unexpectedly. When the CPU is heavily taxed for more than a few seconds, it will draw more power and faulty capacitors will cause the computer to become unstable. I had a computer that would blue screen or reboot when playing videos after several minutes but the rest of the time the computer ran fine. So it is my thinking that the long B4A compiles are causing a lot of work from the CPU which increases a prolonged strain on the faulty caps that results in unstable voltages on your motherboard.

Thanks for thorough feedback. It's definitely a possibility, whoever luckily I don't have to deal with this at the moment (at least for now).
After applying the recommendations by Erel in Post #10, the problem disappeared.

 

[Widget]

Electrolytic Capacitors (Elco's) in power supplies have nothing to do with CPU load. They are there to smooth the DC voltages (+5V, +12V, -5V). If capacitors blow up then probably the manufacturer has used types with too low maximum voltage specification. I have never (in 30 years) experienced any of such Elco problems in PC's. Also if Elco's blow up then they will create a short circuit which in most cases will cause the power supply to permanently fail.

I've got a motherboard that would either reboot unexpectedly or blue screen with high CPU usage. After a few months it started blues screening more often and has gotten to a point that it now blue screens at boot up. This motherboard has several bulging electrolytic capacitors on it. We also repair computers and have encountered a large number of MB's and power supplies with bulging Elco's. I'd be more than happy to sell you the MB for you to test your soldering skills.

BTW, I never said the caps blew up. If they blow up then you're right the power supply will stop working. But I said the Elco's bulge and may leak white material out of the top of the can. When a CPU works harder it consumes more power which is verified by its CPU temperature monitor. This causes a heavier draw on the power supply and if the power supply has bad caps it can cause the computer to reboot unexpectedly. When an elco leaks, it hampers its performance and the operation of the cap becomes marginal. We've had several computers like this and replacing the bulging caps on the power supply has solved the problem. It's gotten so bad we are buying these caps in bulk rather than one or two at a time.