LE Is there any performance issue when dealing with extremely large formlists ?

[Deleted2838758User]

For example, if I had a script that checked if a spell is available in a formlist, would there be any noticable difference is script speed between a formlist containing 30 forms and another containing 800 (Just an example, I don't think it would actually be possible to reach 800 spells unless you download all spell mods on the nexus) ?

[Surilindur]

I have not tested it, but common sense might allow for at least two assumptions (emphasis on assumptions):

1. If you "manually" cycle through the FormList to check if it has the item (which you should NOT do), then it might have a significant impact.
2. If you use the readily available functions, then it might have less of an impact.

It has been quite some time since I last did any Papyrus scripting, but something like this both makes no sense and might suffer from a huge FormList:

Bool Function CustomHasForm(Form akForm)
    int index = YourFormList.GetSize()
    bool found = False
    While (index > 0)
        index -= 1
        If YourFormList.GetAt(index) == akForm
            found = True
            index = 0
        EndIf
    EndWhile
    Return found
EndFunction

So if a passer-by reads this and is about to do something like that above, that passer-by probably should not do it. The readily available functions should be better and might suffer less, one would think, assuming they run the check with real code instead of Papyrus (these I mean --> http://www.creationkit.com/index.php?title=FormList_Script ).

Bool hasIt = YourFormList.HasForm(akForm)

But that is just pure assumption. And since using the readily available functions like HasForm should be obvious, I suppose the real question is how their speed depends on the size of the FormList. I think it should be tested to make sure - so if you can acquire a FormList of 800 items, you could check it. It is the only way of knowing for sure. Chances are it will always be slower, but how much slower, I have no idea. It might also be handy to think if alternatives to things that require massive lists, unless using a massive list is the only option? Maybe.

 

I hope someone else can help you more (as in, help you at all). :tongue:

 

Edit: Whooooo-ops. Sorry. Arrays had length easily accessible, FormLists probably need to use GetSize() instead. Corrected that walking example. :facepalm:

Edited August 15, 2016 by Contrathetix

[lofgren]

I've worked with some really long formlists, with multiple hundreds of items. There definitely appears to be a performance hit if you are using condition functions (as on a magic effect, spell, or alias) or "walking" the formlist as Contrathetix mentioned above (although there are times when it simply cannot be helped). I would say the hit seems relatively minor but it depends on what you are doing.

 

I have one mod that picks the nearest object that is in one of four formlists (each fairly long, in the 10s of items, one list in the 100s of items) BUT not in a fifth formlist which aggregates entries as the script progresses. It does this every two seconds. After 30 minutes or so of play, I start to notice stuttering on my ordinarly stutter-free gaming. Though I have not completely isolated the problem to my mod it seems a likely culprit and terminating the spell does seem to resolve the issue. I would guess that this is one of the most performance-intensive operations you can run on formlists because it is comparing and checking multiple lists that are changing frequently constantly.

[cdcooley]

Yes, it depends on what you are doing. Using GetAt once (as someone in another thread is doing to pick a random item) or HasForm will be reasonably fast even for long lists. Using the formlist with other functions (and there are quite a few that will take a formlist as a parameter) or condition functions are pretty resource intensive if the list is very long. But that still might be the best way to solve the problem. In the real world some problems are just inherently hard.

 

I think lofgren should win a prize for mixing one of the game's most expensive functions (basically anything distance related) with a long formlist. (And doing it every 2 seconds? I hope you meant with a 2 second delay between checks, because if it's on a RegisterForUpdate(2.0) scheme that's definitely the problem.)

[lofgren]

Yep, RegisterForUpdate(2.0) (well registerforsingleUpdate anyway). Every 2 seconds I start a quest that compares these formlists then finds the nearest object that meets the criteria, activates it, adds it to the list of objects to no longer pick from, then shuts down the quest. Then I do it again 2 seconds later.

Edited August 16, 2016 by lofgren

[cdcooley]

If you're doing the RegisterForSingleUpdate at the end of that process then there shouldn't be a growing delay. If you do it at the beginning of the process there might be.

[lofgren]

The issue isn't with the length of the update. The issue is how long it takes to start a quest when it has an alias that can only be filled by checking three separate formlists against a growing fourth list that can include literally hundreds of entries by the time it gets reset. Since the game can't progress until it knows whether or not the quest can start, it produces a stutter.

Edited August 16, 2016 by lofgren

[cdcooley]

That's right, you said you were filling aliases with those form lists. That just proves that long formlists do have a performance impact.

[lofgren]

But like you said, I'm doing some pretty intensive stuff with them. I've never had a problem performing simple functions on even extremely long formlists (multiple hundreds of items). I think your advice above is pretty sound.