Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Quick Reply
Search this Thread
Field Researcher
Original Poster
#1 Old 15th Nov 2020 at 5:31 PM Last edited by lizcandor : 15th Nov 2020 at 5:57 PM.
Default Identifying sources of lag/freezing
I know this game isn't the most debug-able, but is there any strategy for this that people are aware of besides just developing an intuition for what kinds of things will slow down the game?

EDIT: Just occurred to me this wasn't clear - I'm thinking of lag due to my own mods, rather than routing issues and such. Although I do also wonder how to best distinguish lag that is my mods' fault from lag that isn't when I'm testing them - I guess I could just use a really small, routing-issue-free world like Builder's Island, but going for extreme simplification like that might obscure genuine issues my mods would create when running in highly populated worlds, so that doesn't seem like a full solution.
Advertisement
Space Pony
#2 Old 15th Nov 2020 at 6:00 PM Last edited by Battery : 15th Nov 2020 at 6:33 PM.
Hi lizcandor,

the thing you could do is to write a debug message for methods you suspect do be impactful on performance.
So make a call to your Debug method when your target method starts and one when it ends and see when the lag occurs and what messages appear

then you also have to see what kind of lag you get is it just sometimes for a long time then its probably a method that gets called rarely and if its many lags its a method that gets called often, i know thats really basic things you probably already thought of but sometimes theres just a lot of work involved iguring these things out.

I myself try to do very little steps sometimes as little as adding one line of code to see how the mod performs before i go further with the mod. If you already have a large codebase debbuging really can be hard. try to remove all but the most necessary methods from your mod and test how they performe one by one.

Interactions can be really nasty for example. The game loops through all the tests etc reguarly so keep these method as performant as you can
Field Researcher
Original Poster
#3 Old 15th Nov 2020 at 6:28 PM
Quote: Originally posted by Battery
write a debug message for methods you suspect do be impactful on performance

Ah, that's a good idea! The method I'm most suspicious of is the one I use to check if romance is allowed between a pair of sims, since it uses Reflection to be compatible with Woohooer; I'll add a message right before it does the Reflection invocation, and if that message always appears before a lag I'll know I need to change my approach.

Quote: Originally posted by Battery
Interactions can be really nasty for example since the game loops through all the tests etc reguarly so kep these method as performant as you can

Hm, I've got an interaction in this mod with a test function that checks if romance is allowed - that's probably not helping

Thanks!
Space Pony
#4 Old 15th Nov 2020 at 6:39 PM Last edited by Battery : 15th Nov 2020 at 7:45 PM.
thinking about it one could also write sort of a profiler class that stores the method name the times it gets called and how long it took to process.
this could work like this
methodA gets called
Code:
methodA
{
              stopwatch start
              Your Regular Instructions();
              stopwatch end
              DebugClass.mehodAtimes.Add(stopwatch.elapsedtime); //a list that sotres the exec times)
}


and after some time print all of the DebugClass content for every method out ( you can pring min, max and average execution time for example on each method aswell as the sum the game took for all calls) this way you would get an overview over all your methods
Field Researcher
Original Poster
#5 Old 15th Nov 2020 at 6:58 PM
A profiler like that would be awesome! I've missed having that kind of debugging feature so much, you're right that it's totally possible to make our own. Could be a good addition to my common classes assembly - I was thinking I need to incorporate better debugging into that anyway, so this could be an aspect of that. Maybe I can add a repeating alarm that prints a notification onscreen, writes it to a file, and then clears the debugging class and starts fresh.
Virtual gardener
staff: administrator
#6 Old 16th Nov 2020 at 9:51 AM
Quote: Originally posted by lizcandor
A profiler like that would be awesome! I've missed having that kind of debugging feature so much, you're right that it's totally possible to make our own. Could be a good addition to my common classes assembly - I was thinking I need to incorporate better debugging into that anyway, so this could be an aspect of that. Maybe I can add a repeating alarm that prints a notification onscreen, writes it to a file, and then clears the debugging class and starts fresh.
I know this is probably not possible for checking romances between a sim and such, but for the sewing table (and another project I've been working on) I've got this function that takes 3+ seconds to process (which makes sense since it goes through some xml code and then creates patterns from there). Now, what I did was that I moved that function from each time you place the sewing table, to it being processed each time when the game loads a world. That by itself can be a massive change

But overall, the rule of thumb I always use is, if a function takes 1.5 sec to load, then either one needs to look at optimizing the code or move it  Overall I'd highly recommend Battery's method! And, if you've got access to it of course, put those stopwatch methods between bits and pieces of the code that you assume is taking the longest. Because you will be surprised lol
Field Researcher
Original Poster
#7 Old 16th Nov 2020 at 1:58 PM
I sort of found a way to move the slow part of my code! I haven't figured out the best possible place for it yet, but I was able to put it behind a bunch of other checks in most of the places it's used, instead of making it the first check. So it runs a little less often than it did before. Still a lot though Adding a debug message every time it runs was...eye-opening
Back to top