ID:1864345
 
(See the best response by Lummox JR.)
I need to know if there is a tool or a means of making a stress test in my game. My doubt is simple: The resources I need to keep an online player and through the calculation to find out which approximate number of players can achieve in the state where my game is. basically I want to know this to try to minimize this cost to much as possible.
Honestly, as I've always seen done, just make a verb that calls whatever you're stress testing an excess amount of times(10,000 seems a good number for most things I test), activate the debug mode, open up(and start) the profiler, and commencing the test. Even if it's a heavy-usage proc, you can walk away and come back to the profiler results(where you can also check the average usage). Then you either do research on what you're doing wrong and alter it for better optimization or decide you're happy with the results and continue to the next.

Things that you should stress test and optimize the most are the small things that are called often.
You also have to think to yourself how often things will actually be called in a real time situation and sort of budget how much time you can afford to spend on something. Optimization is more about knowing when something is an O(1) problem, an O(N) problem, or an O(N^2) problem, etc.

Usually I just tell people to look for loops.
Check your loops.
Precache everything you can.
Send as much stuff client-sided as you can that makes sense being client-sided.
Use the Dream Daemon Profiler and Memory Usage to check statistics.
Host a testing event and get as many people as possible to check networking, or fake it and create a lot of /mobs and have them do exactly what players would do. Run that for 24 hours and come back to see the results. Check in periodically to see if there's been major CPU spikes and if so, why.
Best response
The profiler is your friend here. What you'll want to do is get some data from the profiler first, looking for procs that take up a lot of time--especially if they take a lot of time per call. (E.g., something that's called a million times but takes 1 second total is probably behaving really well.) Those are the places where you can probably find savings.

When you know which procs to look at, do as Ter suggested and try to cost them out in terms of their complexity. Do you have a loop within a loop? That's likely an O(N^2) situation--meaning if there's a formula that describes the number of operations, its biggest term would be N^2 multiplied by a constant.

General rules of optimization to live by:

- If all or part of a calculation can be done once outside a loop instead of inside, do it outside.
- If a long loop depends on a var like list.len and you know that var won't change, assign it to a local var that can be read faster.
- If a loop is frequently called, regardless of its length, consider seeing if you can do it backwards. Comparing the loop counter to a constant like 0 or 1 is faster than comparing to a var.
- If you can inline something instead of having a soft-coded proc do it, sometimes that's faster because it avoids proc call overhead. #define can help you here.

I'm forgetting a lot of others, but the gist is once you're looking at a routine, you want to eye it carefully and try to figure out if there are any subtle tweaks that could make it faster. If you identify any procs that you want to optimize, I'm sure we can offer some pointers if you post them here.
In response to NNAAAAHH
ty all you help-me alot!
In response to Jkkkg
That's what we're here for! Feel free to come back with details on what you're trying to optimize(in another topic), as we'll be able to help guide you more so, if you need it.