max var's between value or update

[phjvh 0]

Hi,Suffering "fpsitis" and reading threats about max reg's, 50, and statements between value tags, 30, ???? I have a question:Is there really a limit and what is better:(L:Var1,enum) 1== if{...(L:Var2,enum) 2== if{...(L:Var3,enum) 3== if{...........(L:Var200,enum) 200 == if{...or(L:Var1,enum) 1== if{...(L:Var2,enum) 2== if{...(L:Var3,enum) 3== if{...........(L:Var30,enum) 30 == if{...(L:Var31,enum) 31== if{...(L:Var32,enum) 32== if{...(L:Var33,enum) 33== if{...........(L:Var60,enum) 60 == if{...etc.Or is this better:(L:Var1,enum) 1== if{...(L:Var2,enum) 2== if{...(L:Var3,enum) 3== if{...........(L:Var200,enum) 200 == if{...What is better, place all that logic, many elements, in one gauge, or is it better to split them off in several.Little bit dizzy because of fps-disease.Jan"Beatus ille qui procul negotiis..."

[Guest Vorlin]

Jan,It's tough to understand what you're doing from the above. Do you need to check all 200 even if earlier ones are true? If any one is true or false, does that allow you to skip certain other checks?Or are you jsut trying to find the most efficient way to test 200 variables and trigger the appropriate routines?Scott / Vorlin

[phjvh 0]

No, The question is how many statements can be used between tags.And if it is better to use several elements with code or put everything in one element or Jan"Beatus ille qui procul negotiis..."

[rcbarend 37]

Hi Jan,I also realise that there is a restriction of the amout of code you can put in a tag.But I've never been able to figure out, what the exact criterium is.(number of characters, number of "statement", or whatever ???).The only thing I can advise: be aware of it, and split up Elements if you run into this problem.I don't have much experiance with the Update tag (other than Update Frequency), so I would also be interrested to know if there is a size restriction for this tag. (I can only assume: yes)Cheers, Rob

[Varmint007 2]

That's correct. There's definately a limit to the number of if{ } blocks within a single element. I haven't specifically tested to see how many, but I suspect it's tied to the stack limit. The stack doesn't seem overflow if the limit is exceeded, and clearing the stack doesn't fix it, however subsequent logic within the same element seems to be ignored.Best to just break it up into different elements. If you need to check a huge amount of values, perhaps you can use a loop for your application.--Jon

[taguilo 33]

Jan,I, like Rob and Jon, also believe there are physical limits for placing code inside an . Though I never reached any, I always have that in mind and started coding gauges with a big number of "systems logic only" elements, with the idea that splitting the stuff into many would avoid those dreaded limits.Some threads ago you shot the point to use section for all the logic coding and I start testing into that way.Now I've moved some of my most complex code from many elements into the section an found no trouble at all so far (indeed that is pure stack space).Jon said he has found a limit to the number of nested "ifs"; I can't confirm this because I always try to use the least of these as possible; however I've really hung the sim when nesting too many macros, and I'm starting to suspect if this could be related to the "ifs" included in those macros...(there is a recent thread where I posted a complex code placed inside an which was on the limits)Also I like the idea of placing all the logics in one gauge. Tom

[phjvh 0]

Hi,Good Sunday and thanks for your answers.I have no problems with non-functioning code, so i think one more statement between update or value is still possible.Still worried about the size of the stack and FPS.What is better, one large stack or several smaller.Jan"Beatus ille qui procul negotiis..."

[rcbarend 37]

Hi Jan (and others),""Still worried about the size of the stack and FPS""I wouldn't worry about both:- FPS: IMO FPS is hardly influenced by the number of statements, much more by the complexity of the calculations. Even stronger: Optimising a gauge for FPS is the last thing I worry about (just based on experiance and measurements). As you know, I've been quite active in this field, and I have never created an XML gauge that noticeably influenced FPS on a reasonable PC.The only XML gauge I've seen that actually does influence FPS is the GPS gauge. And looking at that code, I can perfectly understand why.- Stacksize.Allthough I still don't understand what this exacty "value/element" limitation is, I'm fairly sure it isn't the stacksize.Because as far as I know, the stack isn't used for code, just for data passing. And the piece of code I had my problem with (last part of the code not executed) hardly influenced the stack: at no time in the code there were more then 20 variables on the stack.So unless someone proves otherwise, I assume the "limitation" we talked about is just an XML parsing limitation of FS9.Cheers, Rob

[taguilo 33]

Jan,""What is better, one large stack or several smaller.""Actually and the whole set of in a gauge shares the same stack space. This said, it is also evident that each element has its own memory section, so if is used, there must be kinda "jump" to the stack space's section, which at first sight seems to be less efficient than processing the data code in a "lineal" way inside (maybe that's the reason for the section to exists).Tom