|
Zulghinlour | Fri 17-Apr-09 12:17 AM |
Member since 04th Mar 2003
9792 posts
| |
|
#24457, "CF Performance"
|
So I continue re-factoring code to make this a smooth running beast. One of the benefits I've seen already is that TICKS actually happen closer to when they should (between 15-45 seconds). Just one of the things I'm now keeping an eye on.
I've added in goals & validation around all functions in our update_handler() function (this basically is what runs the game). If any function exceeds the goals I've set all the IMPs get notified, so we can go make appropriate changes. As of now, the majority of functions have a target goal of 0.03 seconds, there are a few that do the most grunt-work that have a target goal of 0.25 seconds (like mobile_update() which does various things to every mob/character in the game every 4 seconds, and char_update() which is the function that takes care of the TICK for every mob/character).
Right now my hope is to keep the goals less than 0.25 seconds, and add new functionality as necessary to meet those goals.
I know of about a dozen or more things that don't meet these goals right now, and I'm slowly working through them. So long, and thanks for all the fish!
|
|
|
|
FYI:,
Daevryn,
24-Apr-09 01:27 PM, #10
RE: FYI:,
Isildur,
24-Apr-09 02:04 PM, #11
RE: FYI:,
Daevryn,
24-Apr-09 02:24 PM, #12
Mmmm...Thunderdome (n/t),
Zulghinlour,
24-Apr-09 02:46 PM, #13
What language would you use? /nt,
Rodriguez,
24-Apr-09 05:13 PM, #14
Probably C#,
Daevryn,
24-Apr-09 05:20 PM, #15
Dude,
N b M,
24-Apr-09 07:58 PM, #16
C (n/t),
Zulghinlour,
24-Apr-09 08:09 PM, #17
Two bits enter, one bit leaves! nt,
vargal,
25-Apr-09 05:06 AM, #18
I sort of posted about this several years ago.,
Dallevian,
18-Apr-09 12:05 PM, #9
Thanks Zulgh, definitely noticed the improvement. n/t.,
TheDude,
17-Apr-09 09:34 PM, #8
Another thought,
Dwoggurd,
17-Apr-09 04:25 AM, #4
RE: Another thought,
Zulghinlour,
17-Apr-09 12:43 PM, #5
Re,
Dwoggurd,
17-Apr-09 06:05 PM, #7
RE: CF Performance,
Isildur,
17-Apr-09 12:30 AM, #1
RE: CF Performance,
Zulghinlour,
17-Apr-09 12:34 AM, #2
RE: CF Performance,
Asthiss,
17-Apr-09 01:53 AM, #3
RE: CF Performance,
Isildur,
17-Apr-09 12:44 PM, #6
| |
|
Daevryn | Fri 24-Apr-09 01:27 PM |
Member since 13th Feb 2007
11117 posts
| |
|
#24549, "FYI:"
In response to Reply #0
|
I spent most of last night on some fairly mindless refactoring of a handful of things that don't run very fast into equivalents that run faster. Some of these things happen at the tick, some more often.
I don't expect any of it to have near the impact that the stuff Zulg has done to this point did, but that code should be live soon-ish and we'll see. I figured it made sense to start with the things I knew how to do and knew really should have been done a different way.
|
|
|
|
    |
Daevryn | Fri 24-Apr-09 02:24 PM |
Member since 13th Feb 2007
11117 posts
| |
|
#24551, "RE: FYI:"
In response to Reply #11
|
Mostly no (I know where things are crashing, but not what went wrong at some indeterminate point or process before that to cause it) though I have a theory or at least an observation I need to remember to talk through with Zulg at some point.
I swear, if I had a year and nothing to do I'd rewrite CF in a "modern" language just to get away from C's Thunderdome style of memory management.
|
|
|
|
      |
Zulghinlour | Fri 24-Apr-09 02:46 PM |
Member since 04th Mar 2003
9792 posts
| |
|
#24552, "Mmmm...Thunderdome (n/t)"
In response to Reply #12
|
n/t So long, and thanks for all the fish!
|
|
|
|
      |
Rodriguez | Fri 24-Apr-09 05:13 PM |
Member since 30th Jan 2005
367 posts
|
|
|
#24553, "What language would you use? /nt"
In response to Reply #12
|
|
|
          |
N b M | Fri 24-Apr-09 07:58 PM |
Member since 29th Sep 2005
444 posts
| |
|
#24555, "Dude"
In response to Reply #15
|
What is cf actually written with, and what languages are compatible with it.
I am actually delving into C#, all the dif browser languages, Vstudio, SQL, etc..., for work
|
|
|
|
            |
Zulghinlour | Fri 24-Apr-09 08:09 PM |
Member since 04th Mar 2003
9792 posts
| |
|
#24556, "C (n/t)"
In response to Reply #16
|
n/t So long, and thanks for all the fish!
|
|
|
|
      |
vargal | Sat 25-Apr-09 05:06 AM |
Member since 07th Apr 2004
384 posts
| |
|
#24557, "Two bits enter, one bit leaves! nt"
In response to Reply #12
|
|
|
|
Dallevian | Sat 18-Apr-09 12:05 PM |
Member since 04th Mar 2003
1625 posts
| |
|
#24492, "I sort of posted about this several years ago."
In response to Reply #0
|
|
|
|
TheDude | Fri 17-Apr-09 09:34 PM |
Member since 20th Sep 2005
283 posts
| |
|
#24489, "Thanks Zulgh, definitely noticed the improvement. n/t."
In response to Reply #0
|
|
|
|
Dwoggurd | Fri 17-Apr-09 04:25 AM |
Member since 20th Jan 2004
668 posts
| |
|
#24461, "Another thought"
In response to Reply #0
|
Several big functions may not fit 0.25s (a pulse time?). Did you guys consider splitting them into several smaller pieces and spear across different pulses within a tick? For example you could update all characters and mobile hps at a tick front and move mobiles in the next pulse. Then update weather and area repops in a consequent pulse, etc? While, certainly, some things can't be split, I think there are opportunities where you could actually do different updates in different pulses even if it implies slightly changed game mechanics (different != bad).
|
|
|
|
  |
Zulghinlour | Fri 17-Apr-09 12:43 PM |
Member since 04th Mar 2003
9792 posts
| |
|
#24465, "RE: Another thought"
In response to Reply #4
|
>Several big functions may not fit 0.25s (a pulse time?).
That's why I'm tracking the data...to find out.
>Did you guys consider splitting them into several smaller >pieces and spear across different pulses within a tick?
Right now, the functions that are causing things to be out of whack are because they are written poorly, and have been easily refactored into the existing infrastructure. If I get to a point where that is not the case, I'll think about it. I agree different != bad, but there are also things to keep in mind like "Will people be able to determine a tick is coming if XYZ always happens here", which used to be the case with some things. So long, and thanks for all the fish!
|
|
|
|
    |
Dwoggurd | Fri 17-Apr-09 06:02 PM |
Member since 20th Jan 2004
668 posts
| |
|
#24481, "Re"
In response to Reply #5
Edited on Fri 17-Apr-09 06:05 PM
|
>but there are also things to keep in >mind like "Will people be able to determine a tick is coming >if XYZ always happens here", which used to be the case with >some things.
Yep. That may be an issue. So it make sense to keep important things (like hp updates) several pulses ahead of less important things (like weather change).
PS. And notice, that I don't propose to parallelize CF code and move to a fancy multi-core Nehalem-based server
|
|
|
|
  |
Zulghinlour | Fri 17-Apr-09 12:34 AM |
Member since 04th Mar 2003
9792 posts
| |
|
#24459, "RE: CF Performance"
In response to Reply #1
|
>Nice. Any idea what the overhead is for the run-time >performance checks? Seems like something you'd eventually >want to disable once you clean up all the current problem >functions. Then just enable it periodically to see if any new >ones have started misbehaving.
Right now it seems negligible (set a clock_t before calling the function, set a clock_t after calling the function, subtract the clocks and compare against the goal, and report).
I'm actually inclined to leave them in if the overhead continues to prove to be minimal, because I'd rather have some checks in for new code that gets added without having to code review everything anyone checks in, and I'd be curious how some of these functions scale based on the number of players online. So long, and thanks for all the fish!
|
|
|
|
|