API Performance

Hey everyone! I'm working on a new script that will potentially require storing large-ish amounts of data in a nested array that I want to persist between sessions: [[Item1,data,data,data],[Item2,data,data,data],[Item3,data,data,data],...] I'll be looping through to add Items at various points within the array as well as looping through and logging specific items in a chat message.  I don't want to inadvertently create a performance nightmare and bog down the campaign's API and am hoping some of you might know or have some thoughts off-hand. Question 1: At was size does looping through an array and checking a few conditions begin to affect performance? And if my arrays are in that range is jumping to a midpoint then choosing a half until I get to a manageable size to loop through a good work around? Question 2: Would storing this array in a key inside the state object be preferable to (or worse than?) storing the array inside a character attribute and parsing it in and out? For my own personal use of the script I don't anticipate it getting too dense but I want to make it robust enough that it won't crash someone else's campaign if they are using it more intensely (or warn them of it's limitations!). Thanks!

Define "large-ish". If you are storing this data in state, then it's going to be written to the server every few seconds, which can take a while for large amounts of data. However, largely because of scripts storing large amounts of data (a particular script storing all the data on every spell in Pathfinder in state comes to mind), a sandbox can be throttled to prevent problems that would be caused by this. Specifically, to prevent problems your hypothetical script could cause for other people trying to use the API, even if they aren't using your script. (If your script is getting throttled, it could bog down your own execution, but will no longer be an issue for others.) If you are storing the data in some other way, such as in a handout, throttling isn't an issue. You will run into asynchronous coding when you retrieve the value stored, but you shouldn't need to do that often (you can cache it in memory on ready instead of retrieving it every time you need data). At that point, I return to my previous request, "define 'large-ish'". You're not going to see notable delays iterating over a collection in JavaScript unless the actions you're taking on each element are particularly slow, or the size of the collection is to the tune of tens or hundreds of thousands of items or more.

Sorry, I should have been more specific. I'm expecting on average to have 40-50 sub-arrays (each containing 5 items, one string value of variable length, two 2 digit numbers, one 4 digit number, and one two character string) on average. A high test case would probably involve 200 or so. It sounds look the iterating won't be an issue since I will just be checking a handful of conditions and writing a few lines data to a variable each iteration. But is that too much to throw into state?

1,000 objects is not "large" when it comes to computing. You've got another order of magnitude  before I would even begin considering optimization due to data size. Each sub-array is approximately (28 + variable string length * 2) bytes plus the overhead of an array (which varies by JS implementation; I believe IE is the worst at 92 bytes of overhead). From that, if we take an average length of your variable-length string at 4 characters, the size of your 200-element array if stored using IE's implementation of JS would be about 25,692 bytes (25 kilobytes and change). Writing 25k to storage every 5s should not be an issue, although I'll freely admit I don't know the full details of how state is managed by the server.

Thanks for the help Brian, I really appreciate it!