Paul_Hoffman's Profile

  • Name: (Private)
  • Email: (Private)
  • Member Since: Jul 7, 2008
  • Last Logged In: Nov 19, 2009 2:00 PM
  • Status Level:  
  • Location: RTP, NC
  • Occupation: Software Engineer
  • Biography: Paul has spent many years as a member of the VAG and EGL / RBD development teams. He is currently enjoying his role as "customer advocate" because he gets to help users on a variety of interesting issues.
  • Expertise: Paul came from an MVS mainframe background early in his career so he knows how to spelll IMS and CICS. He picked up a little C, Java, DL/I, SQL and Web experience along the way, but of course thinks EGL is the easiest way to build a business application.

Paul_Hoffman's Latest Content

EGL programs are transformed (we call the process "generation") to Java, COBOL, or JavaScript programs for deployment in a target runtime environment.

If performance of the generated program is significant to you, then it is important to understand the performance characteristics of EGL syntax alternatives in the different runtime environments.


A new white paper, EGL Best Practices: Coding For Performance, provides insight into this topic for EGL programs destined for Java or COBOL environments.

Please feel free to use this document. Comment on information that you feel was especially important to you or point out issues or scenarios that you would like addressed with more detail.

0 Comments Permalink

Many customers include logging or tracing capabilities in their large applications. At times we've seen situations where applications perform poorly and one of the issues was the amount of resource being consumed by application traces that developers forgot to remove before conducting the performance evaluation. You can minimize performance problems related to logging overhead by following one simple rule: make sure any logging done from the main line path of your production applications can be turned on or off without regenerating your program.

The following table illustrates the importance of making your log invocations conditional. The table lists some measurements made using the simple logging library attached to entry. The log library includes a logging control switch that can be used to turn logging on and off.

Scenario repeated one million times Java Time In Seconds Cobol Time In Seconds
Library writes log record to file 260 360
Library log function checks switch and returns without writing record to file 0.2 1
Client checks global library switch and does not invoke log function 0.1 0.7
Client checks local copy of global library switch and does not invoke log function 0.01 0.01

Some observations:

  • The overhead of checking a switch is very small compared to the overhead of writing log or trace records. It's reasonable to leave logging or tracing calls in a production program as long as the actual writing of the log entries can be turned on or off.
  • Logging of application failures or exceptions should not be conditional. This will not hurt performance as long as the logging is down on an exception path. The logging library includes log error functions whose behavior is not controlled by the logging switch.
  • Do not draw any conclusions about the relative merits of Java and Cobol from the table. The measurements were taken on different machines and comparisons between the two languages for the same scenario are not meaningful.

0 Comments Permalink

Over the past several months, the RBD team has been working with several customers on questions related to the performance of EGL applications. The scenarios can be as simple as a batch job taking longer to run than expected or as complex as a large JSF application not meeting a Service Level Agreement for the number of active users, the transaction throughput rate, and the response time.

This blog is intended to be a place for sharing best practices for the creation of EGL applications that perform well. We will talk about which alternative ways of coding EGL programs that produce best results in each environment or the most acceptable result across all environments. We'll solicit recommendations on how to measure resource consumption, how to put a repeatable load on your system, or how to locate the culprit in a problem situation.

We value your contributions to this blog as well. Please comment on what performance topics would be most useful to you or propose a topic for sharing your experiences with others as a guest blogger.

Looking forward to hearing from you!

0 Comments Permalink

Brainstorm with co-workers, get your questions answered, build status with your responses.

Write your own drafts, invite selected collaborators, or leave it open for all to pitch in.