PDA

View Full Version : Performance of effects



Kelrugem
September 16th, 2019, 03:15
Hi :)

I plan to extend the usage of the operator IF (and IFT) in one of my extensions by implementing some sort of inverted IF. Thence I want to improve the performance of such things like IF because users of that extension are more likely to use it then. I am looking into manager_effect_35E.lua (so it is also about 3.5e) and see the following function for testing whether some conditions for IF are met: (if you need further information then please ask; but it might be good if you know a bit that file)


function checkConditionalHelper(rActor, sEffect, rTarget, aIgnore)
if not rActor then
return false;
end

local bReturn = false;

for _,v in pairs(DB.getChildren(ActorManager.getCTNode(rActor ), "effects")) do
local nActive = DB.getValue(v, "isactive", 0);
if nActive ~= 0 and not StringManager.contains(aIgnore, v.getNodeName()) then
-- Parse each effect label
local sLabel = DB.getValue(v, "label", "");
local bTargeted = EffectManager.isTargetedEffect(v);
local aEffectComps = EffectManager.parseEffect(sLabel);

-- Iterate through each effect component looking for a type match
local nMatch = 0;
for kEffectComp, sEffectComp in ipairs(aEffectComps) do
local rEffectComp = parseEffectComp(sEffectComp);
--Check conditionals
if rEffectComp.type == "IF" then
if not checkConditional(rActor, v, rEffectComp.remainder, nil, aIgnore) then
break;
end
elseif rEffectComp.type == "IFT" then
if not rTarget then
break;
end
if not checkConditional(rTarget, v, rEffectComp.remainder, rActor, aIgnore) then
break;
end

-- Check for match
elseif rEffectComp.original:lower() == sEffect then
if bTargeted then
if EffectManager.isEffectTarget(v, rTarget) then
bReturn = true;
end
else
bReturn = true;
end
end
end
end
end

return bReturn;
end

Might the following code not be better for the performance? (new things in red)


function checkConditionalHelper(rActor, sEffect, rTarget, aIgnore)
if not rActor then
return false;
end

for _,v in pairs(DB.getChildren(ActorManager.getCTNode(rActor ), "effects")) do
local nActive = DB.getValue(v, "isactive", 0);
if nActive ~= 0 and not StringManager.contains(aIgnore, v.getNodeName()) then
-- Parse each effect label
local sLabel = DB.getValue(v, "label", "");
local bTargeted = EffectManager.isTargetedEffect(v);
local aEffectComps = EffectManager.parseEffect(sLabel);

-- Iterate through each effect component looking for a type match
local nMatch = 0;
for kEffectComp, sEffectComp in ipairs(aEffectComps) do
local rEffectComp = parseEffectComp(sEffectComp);
--Check conditionals
if rEffectComp.type == "IF" then
if not checkConditional(rActor, v, rEffectComp.remainder, nil, aIgnore) then
break;
end
elseif rEffectComp.type == "IFT" then
if not rTarget then
break;
end
if not checkConditional(rTarget, v, rEffectComp.remainder, rActor, aIgnore) then
break;
end

-- Check for match
elseif rEffectComp.original:lower() == sEffect then
if bTargeted then
if EffectManager.isEffectTarget(v, rTarget) then
return true;
end
else
return true;
end
end
end
end
end

return false;
end

As you can see I removed bReturn. When that variable is true then the condition is met, otherwise not. bReturn can only become true in that for loop and in that for loop bReturn can not become false again once it became true. Thus, it should be okay to break the loop with return true. The problem I see is that that for loop goes through all effects; even when it is known that the condition is already met/found it still iterates through the remaining effects. Moreover, when there are other IF effects etc. it starts other functions with other loops although this is not really needed once bReturn became already true.

Am I right? Or do I miss something really crucial? :) I did not upload this yet because it is about effects and I am afraid of breaking the effect structure of the users of that extension :)

Thanks in advance :)

Kelrugem

PS: A similar argument for the function checkConditional, but I think that there it is less of a problem :)

Moon Wizard
September 16th, 2019, 19:08
Looks like there is some cleanup that could happen in those functions. These functions have evolved over time. I'll try pushing some updates to Test channel pretty soon to try some changes.

Regards,
JPG

Kelrugem
September 16th, 2019, 19:10
Looks like there is some cleanup that could happen in those functions. These functions have evolved over time. I'll try pushing some updates to Test channel pretty soon to try some changes.

Regards,
JPG

Cool, thank you very much :) I am looking forward to it :)