Lifetime Management

[jimka...@gmail.com]

I have a question about lifetime management. I think I know the answer, but would like verification.

Lets say that I have a quest that uses a JFormMap as a database to track some things about certain NPCs. I need the JFormMap object to stick around for a long time, probably much longer than 10 seconds, as I may want to recall the information at any point in the future. Is it necessary to retain the JFormMap after creating it? I think the answer is yes, but I want to be certain.

As an very basic example, would the following code be correct? Assuming it is, when I stop the script and prepare to uninstall the mod, I would want to call release(friends) or releaseObjectsWithTag("myfriends"), right?

Scriptname myfriends Extends Quest

int friends

Event OnInit()

    friends = JFormMap.Object()

    JFormMap.retain(friends, "myfriends")

EndEvent

[jimka...@gmail.com]

Just a slight correction, but I think I would actually need to call JValue.retain(friends, "myfriends") instead of JFormMap.retain(friends, "myfriends"). Likewise, calls to release would be JValue.release(friends). Is that correct?

On a related note, if I were to use JFormDB to store my data instead, am I correct that I would not need to retain anything? When I want to uninstall my mod, how would I delete the unneeded data from JFormDB?

[slifeleaf]

> Is it necessary to retain the JFormMap after creating it? I think the answer is yes, but I want to be certain.

yes

> As an very basic example, would the following code be correct? Assuming it is, when I stop the script and prepare to uninstall the mod, I would want to call release(friends) or releaseObjectsWithTag("myfriends"), right?

It looks ok to me. I'd call 'release' only. releaseObjectsWithTag is mostly for maintenance purposes, like when a one not sure whether all objects in his code were released. And releaseObjectsWithTag can be slow as the function iterates over all objects, releases the objects with given tag

> On a related note, if I were to use JFormDB to store my data instead, am I correct that I would not need to retain anything? When I want to uninstall my mod, how would I delete the unneeded data from JFormDB?

In case of JFormDB you don't have to retain anything because all the data is part of JDB tree.

-- Will destroy everything "yourModFormStorage" contains
JDB.setObj("yourModFormStorage", 0)

> Just a slight correction, but I think I would actually need to call JValue.retain(friends, "myfriends") instead of JFormMap.retain(friends, "myfriends"). Likewise, calls to release would be JValue.release(friends). Is that correct?

Yep

[slifeleaf]

> In case of JFormDB you don't have to retain anything because all the data is part of JDB tree.

And JDB is just a single instance of JMap, retained internally

[jimka...@gmail.com]

Is it more efficient to use JDB or JMap? Since JDB is just an instance of JMap, I assume they are equivalent, but I wonder if there are any optimizations behind the scenes.

[slifeleaf]

They are absolutely equivalent and there are no optimizations. JDB access can be slower only in case when two or more threads accessing it simultaneously, very and very often, I mean some really crazy, out-of-norm frequency, just because any container object locks itself when being accessed

[slifeleaf]

I mentioned JDB only because its underlying JMap is shared by much more devs/mods than any other container

[jimka...@gmail.com]

That makes sense. I hadn't considered the case where multiple threads want access to JDB, so thanks for pointing that out. Although, I'm sure the load would have to be really heavy for it to be an issue.

Thanks a lot! I think I have a good idea now about how these containers will fit into my mod. 

[Arocide]

This has me curious, If there are child objects are they locked as well when the parent is accessed? or is it a shallow lock?

[silverice]

the parent locks itself only, you still can access the child objects if their identifiers are known

On Mon, Apr 13, 2015 at 9:47 AM, Arocide <aro...@gmail.com> wrote:

This has me curious, If there are child objects are they locked as well when the parent is accessed? or is it a shallow lock?

--
You received this message because you are subscribed to the Google Groups "jcontainers-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jcontainers-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jcontainers-users/a3b2284a-2adc-40bf-ba83-3b9b6a89880d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arocide]

Ahh, nice lazily using the JDB to manage lifetime is a totally legit strategy!

[slifeleaf]

You may also wrap calls to JDB via properties for convenience (like `int property followers hidden` with get/set functions instead or retain/release), or add your objects into a pool
and store identifiers in script's fields

And welcome! I didn't noticed that you joined until now

[Arocide]

Interesting... I never thought about wrapping calls via properties, I usually just create, keep the identifier in a field for the main script that needs it and then add it to the JDB so others can access it if needed I found it worked nicely. Which is why I was curious about the lock.

[Arocide]

 Thanks :D.

[Anthony Hubble]

This is interesting. So if I have multiple threads accessing different parts of a JArray of forms all at the same time, then the overall execution speed is bottlenecked by each thread needing to wait until the JArray is no longer being accessed by another thread?

I'll need to test this to see if this causing the limited benefit I see from multithreading the processing of the player's inventory (which has been dumped into a JArray). I might get a speed up from splitting the JArray into as many parts as there are threads (on the other hand, it could be all those numerous other functions being called on the forms that could be causing the bottleneck).

[slifeleaf]

On Friday, April 17, 2015 at 8:44:38 AM UTC+3, Anthony Hubble wrote:

This is interesting. So if I have multiple threads accessing different parts of a JArray of forms all at the same time, then the overall execution speed is bottlenecked by each thread needing to wait until the JArray is no longer being accessed by another thread?

I'll need to test this to see if this causing the limited benefit I see from multithreading the processing of the player's inventory (which has been dumped into a JArray). I might get a speed up from splitting the JArray into as many parts as there are threads (on the other hand, it could be all those numerous other functions being called on the forms that could be causing the bottleneck).

It may be bottlenecked only if you spent enough time inside some shared container.
The benefit of splitting depends on what functions you use. `get/set` are very fast (index access) functions; `find` linearly depends on array's length, it's O(n)
 

[slifeleaf]

On Friday, April 17, 2015 at 8:44:38 AM UTC+3, Anthony Hubble wrote:

I'll need to test this to see if this causing the limited benefit I see from multithreading the processing of the player's inventory (which has been dumped into a JArray). I might get a speed up from splitting the JArray into as many parts as there are threads (on the other hand, it could be all those numerous other functions being called on the forms that could be causing the bottleneck).

Would be interesting to look at the results. From what I know the major performance bottleneck can be caused by Skyrim latent functions (like getAV. would be good to have a list), those are queued and executed one-by-one in a single thread.