ABCL efficiency and build settings

[Mark Evenson]

> On Nov 9, 2018, at 02:48, ThutmoseIII Thoth <thutmosethree at gmail.com> wrote:
> 
> Greetings ABCL developers! 
> 
> I have built an application with ABCL and am very pleased with both ABCL and my application, but I would like some help and suggestions in terms of the efficiency of my program, building settings, and perhaps JVM tuning. In the OS X Activity Monitor, my application is reporting to be using 29 threads and 200% of the CPU — This is enough to make my computer HOT to the touch! The equivalent program was running with CCL and cocoa at about 70% CPU and about 10 threads and was not hot to the touch… 
> 
> My program is fairly simple in that it just displays images in a JFrame that it gets from bytes over a socket. For this program I decided to handle each socket and display on its own thread, so I’ve only created two additional threads. 
> 
> I “built” the program by compiling all the .lisp files into .abcl files, then writing a tiny Java main function which creates an Interpreter and loads each .abcl file and finally calls Interpreter.eval on a lisp function which starts the program. I am using the Oracle Java 1.8 Hotspot JVM and ABCL 1.5.0 built from source.
> 
> Thank you and please write back with suggestions and questions that will help me make my program run more efficiently.


Greetings, and welcome to ABCL.

Would it be possible to point to the source of your program?  

It would be great to help you tune your application as a “for instance” as opposed to providing general approaches.  The process of profiling your application could make an instructive case for others. 

“Advanced techniques” would include using the low-level JVM interfaces  (JDP?  Not sure what is current here) to attach profilers for underlying JVM method calls, object allocation etc. for which analyzing the running code as a “black box” will give strong hints at performance bottlenecks.

First hypothesis:  it is not ABCL per se that is having problems, but the underlying JVM.  If you coded your current application in pure Java, would it have the same performance problems on your current hardware?

Again, being able to look at exactly how you are hooking the threads up may show something that is spinning needlessly, so examining the source code itself will great speed up the process. 

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."