(9888) Java Performance and Tuning?
(9888) Java Performance and Tuning?
We have installed java 1.4.1 on our OpenVMS System. A java program, compiled and run on a Windows XP system using SAX to parse an XML file then write a modified file in another location based off information in the XML. This program, when run on the development machine, will go through a 2000 line XML file in 300 milliseconds. When run on the OpenVMS system, will take 4000+ milliseconds. All Java environmental variables have been set according to the Java$check_environment. I am also using the JavaVM Fast (Classic produces even worse results). There is a lot of page faulting as the program runs, reading a line, writing a line through SAX. What is the issue that could be causing the tremendous performance difference? This seriously affects our processing of very large XML files.
Last edited by marty.stu on Thu Aug 18, 2022 10:00 am, edited 1 time in total.
Re: (9888) Java Performance and Tuning?
Java is not a language that would immediately occur to the OpenVMS Wizard for a performance-critical application -- like many similar approaches throughout computing history, Java trades off relative application performance and relatively higher resource usage for a very high degree of program portability.
As has been the case with USCD pCode and other interpreters and as is the case with Java, if you want raw performance, you will probably not want to use an interpreter-based implementation.
This is the case on any and all platforms.
As the OpenVMS Wizard expects you will want to continue here with Java, do consider increasing process quotas, as it appears (based solely on your description) that the process working set or free system memory is insufficient.
Do also ensure that process quotas are appropriately large, and that files are in the native Stream LF format (file conversion details are in the Java documentation), and that the RMS and file system operations are tuned for performance -- that the XML files are set for Stream LF, for instance.
But again, an implementation based on an interpreter is not necessarily the best implementation choice for performance-sensitive application processing. The Java design center is extremely high application portability, and Java excels as an implementation language choice for applications that match its design center.
As has been the case with USCD pCode and other interpreters and as is the case with Java, if you want raw performance, you will probably not want to use an interpreter-based implementation.
This is the case on any and all platforms.
As the OpenVMS Wizard expects you will want to continue here with Java, do consider increasing process quotas, as it appears (based solely on your description) that the process working set or free system memory is insufficient.
Do also ensure that process quotas are appropriately large, and that files are in the native Stream LF format (file conversion details are in the Java documentation), and that the RMS and file system operations are tuned for performance -- that the XML files are set for Stream LF, for instance.
But again, an implementation based on an interpreter is not necessarily the best implementation choice for performance-sensitive application processing. The Java design center is extremely high application portability, and Java excels as an implementation language choice for applications that match its design center.
Last edited by marty.stu on Thu Aug 18, 2022 10:02 am, edited 1 time in total.