Question on EVAL

Hi Boneyard,

you’re right. My initial posting consisted two independent questions in one... ;-)

1.) Does the outlined coding technique have serious TMM side effects (e.g. massive memory consumption on each connection) compared to regular iRules?

2.) Would it be still “safe to use” if the code gets bigger than 64k?

Well, the code base on our production environments is already spanning multiple iRules and each additional iRule produces some overhead to check the results from previous iRules. So the workaround of chaining multiple iRules is unfortunately not that ideal…

And the 64k limit is indeed not the only reason why I’m currently interested in evaling static:: variables. In addition I have also noticed that the contained TCL code does not follow the limitations of SOL13253. The code could be modified/optimized (even by itself), then become byte-compiled again on the very next execution and then affects every established connection pointing to this code structure. So configuration changes will become active at your fingertips...

There are also some additional possibilities to further optimize the code structures. Below are a few examples of the things I’ve currently in my mind to optimize the execution of the evaled code structures.

1.) Perform a complete substitution of static:: configuration values during RULE_INIT and not on every consecutive connection/request.

2.) Evaluate “if $static::x …” or “switch $static::x …” configuration decisions during RULE_INIT. Basically you could change a string, a single TCL command, an entire line, a code block or even an entire code path on the fly based on configuration variables, datagroups or tcl lists without evaluating the config on every connection/request. If the global configuration variables are changed, make sure to flush the caches and rebuild the code structure right after...

3.) Create runtime generated, highly optimized code paths for consecutive request based on a combination of well-known runtime variables / array elements without using a rather complex "foreach" iteration or multiple “if …” or “switch …” decisions.

4.) Precompile entire code structures by resolving, iterating and chaining TCL code blocks fetched from procedure outputs (e.g via return {body}) . It’s a kind of procedure based coding style without calling a procedure at runtime - its some sort of TCL macro'ing. By doing so a code can become as granular as a developer can think of without scarifying overall performance due to repeated calling of procedures and executing code or mapping variables across different runtime levels.

5.) Time will tell... throwin some sideband connections and even background/garbage collection tasks to maintain the cached code structures and let your mind flow...

Cheers, Kai