Is there an upper limit to the number of static variables in an AFL application?

I have an application written in AFL with the help of a C++ plug-in. It loads quite a lot of static variables upon startup using a bunch of #include_once statements like this,

#include_once "Formulas\Include\Runbooks\USMaster\"
#include_once "Formulas\Include\Runbooks\P1Master\"
#include_once "Formulas\Include\Runbooks\P2Master\"
#include_once "Formulas\Include\Runbooks\USGvtBnd\"
<... and so forth ... about  50 such statements ...>

In each of these files, there is a list of variables modularized according the name of an associated watchlist and stored in static variables like so,

	StaticVarSetText(WLNAME+"triggerList", TRIGGERLIST, True);
	StaticVarSetText(WLNAME+"nearVol", NEARTERM_VOLATILITY, True);
	StaticVarSetText(WLNAME+"midVol", MIDTERM_VOLATILITY, True);

	StaticVarSet(WLNAME+"omegaType", OMEGA_SWITCH, True);
	StaticVarSet(WLNAME+"omegaCashType", OMEGA_CASHSWITCH, True);
	StaticVarSet(WLNAME+"omegaTrade", OMEGA_TRADESWITCH, True);

	StaticVarSet(WLNAME+"slowlb", SLOWLB_MULTIPLIER, True);
	StaticVarSet(WLNAME+"fastlb", FASTLB_MULTIPLIER, True);
<and so forth... there are about 80 such variables for each module>

In total, this is about 4000 static variables being stored. Additionally, there are various other places where static variables are created and stored during run-time.

With the latest module I've added, I've run into a situation where the very last variable isn't being created or updated when the program loads. I haven't been able to find a reason for this and am wondering if I've bumped into some limit AB has on the number of static vars which can be in the DB? If so, what is it? Knowing would help me plan any winnowing I might need to do.

There is no hard-coded limit in software.

But you are limited by hardware, i.e. RAM and by free disk space (if your saving persistent variables) and the operating system / runtime library (2GB max single file size on certain file systems)

Use StaticVarInfo:
to get knowledge about your usage.

1 Like

Update on this: I "fixed" this problem by cutting and pasting the #include_once statement from the end of the list to the top of the list. That's it. It now loads properly and the new last item also loads properly. There was no other change in code and obviously no change in resource requirements. Very odd.

It is good programming practice to keep all includes at the top (regardless of language). And bad programming practice to keep them spread across entire file.

FWIW, the includes are at the top of the file. There's just a long list (as described in my original post). I cut and pasted the last entry in the list to the top of the list and the problem was "fixed".

As I wrote, check if you are not exceeding 2GB of persistent variables.