The first part of understanding how your application uses memory involves an initial evaluation of the application.  Check for the following potential causes of memory fragmentation:

•heavy use of the keywords: copy, append, extract...take, add, insert, read file, overwrite, clear, delete, resize array

•calls to DLL functions that create or return string values, including your own, or those supplied with ESL, especially FILEIO,  DDE, APPC,  ESLSTR, and CICS since the amount of data returned can be very large

•calls to ESL subroutines which have local variables  

•any cases where you are dealing with very large string variables  (more than 5 or 10 K)

•any cases where you are iterating (looping) with the above

Do not be concerned if your application does all of this; none of these things is wrong, you simply must be aware of how much memory they might consume before you have a chance to do a "squeeze memory".  By understanding how and when memory is being used up, you will know how often you will need to take this corrective action.

It is useful to think of your application as a set of "transactions".  Usually a transaction is a process which is initiated by the user, which has some series of steps during which there is no convenient ending point, which rely on some related sets of data and which typically return to a starting point.  An application may be composed of one or many transactions.  For example, an order-entry application might present a dialog box requesting that the user choose from a list of customers, then present an order entry screen where the user enters the product information, and then a payment screen where the application makes a total and accepts payment for the chosen products.  All three of these screens together might represent a single transaction.

Your job as the application designer is to figure out based on what data your application needs, and how your program is structured, the maximum amount of memory that might be required by the biggest possible transaction.  Say for example that you have a multi-line entry field into which a user might type lots of data.  If you then copy the text of that MLE to a variable, then pass that variable to a DLL function, you might need three times the storage as the size of the value (one for the MLE, one for the variable, one for the value operated on by the function).  Don't waste your initial investigation time with little things; look for the big things like this.

Also, look for cases where strings are operated on over and over, such as in a loop.  Multiply the number of loops by the typical size (number of bytes) of the string -- if you get a number bigger than 5,000 or 10,000 then look at what is going on.  For example:

would cause concern.  Not only will StringVal come out of the loop being at least 10K, but since it is getting bigger every time, this is a classic cause of memory fragmentation (like the example at the beginning of this page) so ESL would need to allocate larger and larger segments of memory to hold the new value of StringVal at each iteration -- at the extreme, this loop would use up a total of (10 + 20 + 30 + 40 + 50 + 60 + 70 + ... + 10000) bytes.  This is a lot of memory for such a little piece of code.

So, now that you have done your basic checking, you might want to fine-tune your diagnosis to really see where memory is being used up.  A convenient trick with ESL is the use of “EslMemStats” to write out to the error log a "snapshot" of the current memory. By subtracting the “Total Used Memory” before a large transaction from the value after the transaction is complete, it is easy to calculate the memory required. You should always run such diagnostics a number of times and use an average value.