On introducing Parameterization and Correlation concepts differently in LR trainings

[textile]

Two things that confuse the hell out of LoadRunner newbies are the concepts of parameterization and correlation. Most training programs introduce these concepts from the perspectives of file-based input and server-related inputs and talk about the API functions that support them much later.

Here's something that worked on one of my training programs. I look at variables from an ANSI C perspective. For folks with a C programming background, this context tends to maker introduction to these concepts that much easier.

To start with, the lives of variables are simple and have four elements:
Declaration: What basic data type is this variable?
Allocation: Where is this value going to be stored?
Assignment: What is the value to store in this variable?
Destruction: How to return the memory back to the system once the variable is not needed?


In LR programs - which must neccessarily be ANSI C compliant - you have three types of variables:

1. Stack-based variables
Variables declared on the stack have addresses in the stack region.

These are simple declarations:
@int i;@
@char j(5);@ // Can't seem to get the square brackets to work in this blog - still figuring that out.

Allocation: On Windows platforms, your stack is a fixed chunk of memory with a maximum size and a defined location. Ergo, no explicit allocation is needed.

Assignment:
@i = 10;@
@strcpy(j, "this");@

The destruction of stack-based variables are automatic. Once the scope of the program/function ends, the stack frame is destroyed and so is your variable.

2. Heap-based variables
These are accessed via pointers to memory locations and need explicit allocation.
@int *pInt;@
@char *pStr;@

Allocations: Explicit calls to malloc() must be made. Internally they translate into a call to HeapAlloc() and then VirtualAlloc().

@pInt = (int*) malloc(10*sizeof(int));@
@pStr = (char*) malloc (20*sizeof(char));@

Assignment:
@pInt(0)= 1; pInt(1) = 2;@ // Same square bracket problem. Any blog experts who can help?
@strcpy(pStr, "This");@

Destruction: This must be done explicitly using free()
@free(pInt);@
@free(pStr);@

3. LR-managed variables.

All LR-managed variables are heap-based variables and LR abstracts the complications of managing their life from the user. All you need is two API functions which take care of everthing.

@lr_save_string ("12345",@ //The value to assign - basically Allocation and Assignment happen in this line itself
@"My_LR_Variable");@ // The name of the variable i.e. Declaration

Destruction:
The scope of your variable is as long as your vuser context is active and running. Which is the same as heap-based variables. There's no known way (at this point) to get lr_save_string() to destroy the variable explictly.

*Aside on Value Retrieval*:
Invoking lr_eval_string() on LR-managed variables is a costly affair. The pointer returned is not freed, which means a rather marked memory leak. One way to get around this is to go with the

lr_eval_string_ext() and lr_eval_string_ext_free() route. I've explained this with a code snippet and Before and After snapshots of memory utilization (Private Bytes - process) on the support site.

Parameterization can now be introduced simply as a replacement for the lr_save_string() call. Correlation can be introduced as a correlated parameter, with the source now changing to web_reg_save_param() call. The attempt is to introduce a sense of continuity among these concepts to make the training easier and more effective.