EGL Café | EGL Performance - Hints, Tips and Interesting Facts

EGL Performance - Hints, Tips and Interesting Facts

3 Posts

Coding For Performance

Posted by Paul_Hoffman Nov 19, 2009

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

Low Impact Logging

Posted by Paul_Hoffman Jun 5, 2009

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 Tags: logging, performance, egl

Performance and EGL

Posted by Paul_Hoffman Jun 5, 2009

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!